From matthew.brett at gmail.com  Thu Jul  3 12:49:45 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 3 Jul 2014 11:49:45 +0100
Subject: [Cython] Travis-ci builds of OSX wheels
Message-ID: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>

Hi,

We just got scikit-image OSX wheel builds more or less fully automated
on travis-ci :

https://travis-ci.org/scikit-image/scikit-image-wheels
https://github.com/scikit-image/scikit-image-wheels

Any interest in getting the same thing working for Cython?

Cheers,

Matthew

From robertwb at gmail.com  Fri Jul  4 06:51:46 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 3 Jul 2014 21:51:46 -0700
Subject: [Cython] Travis-ci builds of OSX wheels
In-Reply-To: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
References: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
Message-ID: <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>

Sure!

On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> We just got scikit-image OSX wheel builds more or less fully automated
> on travis-ci :
>
> https://travis-ci.org/scikit-image/scikit-image-wheels
> https://github.com/scikit-image/scikit-image-wheels
>
> Any interest in getting the same thing working for Cython?
>
> Cheers,
>
> Matthew
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel

From matthew.brett at gmail.com  Sat Jul  5 00:04:12 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 4 Jul 2014 23:04:12 +0100
Subject: [Cython] Travis-ci builds of OSX wheels
In-Reply-To: <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>
References: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
 <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>
Message-ID: <CAH6Pt5qVKgiUb_Xvy9yHULjXwfQM3ztyd9eeWDAZtVJLSBkiDg@mail.gmail.com>

On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
> Sure!
>
> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> Hi,
>>
>> We just got scikit-image OSX wheel builds more or less fully automated
>> on travis-ci :
>>
>> https://travis-ci.org/scikit-image/scikit-image-wheels
>> https://github.com/scikit-image/scikit-image-wheels
>>
>> Any interest in getting the same thing working for Cython?
>>
>> Cheers,
>>
>> Matthew

Done:

https://github.com/matthew-brett/cython-wheels
https://travis-ci.org/matthew-brett/cython-wheels
http://wheels.scikit-image.org

When y'all have permission, you should be able to click on the refresh
button on the travis page and get built wheels in the http directory,
after 20 minutes or so.  It's set up to checkout and build the latest
tag'ed commit.

Feel free to just clone this repo and push to the Cython organization.
I can then send you a PR updating the rackspace credentials to match
the new repo.

Cheers,

Matthew

From stefan_ml at behnel.de  Sat Jul  5 12:34:48 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 05 Jul 2014 12:34:48 +0200
Subject: [Cython] memory view creation during cascaded assignments
Message-ID: <53B7D4C8.4070406@behnel.de>

Hi,

I started optimising cascaded assignments a little to reduce the
unnecessary duplication of coercions. While doing that, I found this test
in memslice.pyx:

'''
def cascaded_buffer_assignment(obj):
    """
    >>> A = IntMockBuffer("A", range(6))
    >>> cascaded_buffer_assignment(A)
    acquired A
    acquired A
    released A
    released A
    """
    cdef int[:] a, b
    a = b = obj
'''

It's explicitly tested for that we create two independent memory views in
this case. Is there an actual reason for this? As long as the types of a
and b are identical, I don't see why we would want to request the buffer twice.

Stefan

From markflorisson88 at gmail.com  Sat Jul  5 14:49:14 2014
From: markflorisson88 at gmail.com (Mark Florisson)
Date: Sat, 5 Jul 2014 13:49:14 +0100
Subject: [Cython] memory view creation during cascaded assignments
In-Reply-To: <53B7D4C8.4070406@behnel.de>
References: <53B7D4C8.4070406@behnel.de>
Message-ID: <CANg26EXiOO73D0-9qJWhNu=h6YbDEE9KKWTxK+7KnhnHTcs=bQ@mail.gmail.com>

Hi Stefan,

On 5 July 2014 11:34, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I started optimising cascaded assignments a little to reduce the
> unnecessary duplication of coercions. While doing that, I found this test
> in memslice.pyx:
>
> '''
> def cascaded_buffer_assignment(obj):
>     """
>     >>> A = IntMockBuffer("A", range(6))
>     >>> cascaded_buffer_assignment(A)
>     acquired A
>     acquired A
>     released A
>     released A
>     """
>     cdef int[:] a, b
>     a = b = obj
> '''
>
> It's explicitly tested for that we create two independent memory views in
> this case. Is there an actual reason for this? As long as the types of a
> and b are identical, I don't see why we would want to request the buffer twice.

I think it's mostly for simplicity, since any reaching definition is
cleared at the end of the function. Are you thinking to generally
implement this? I suppose you could assign the coercion to a new
variable and replace all use sites (e.g. all the coercions in the
cascaded assignment) with that variable.

     obj = ...
     a = coerce obj int[:]
     b = coerce obj int[:]

->

    obj = ...
    tmp = coerce obj int[:]
    a = tmp
    b = tmp

These transformations may be easier on a three-address code-like
representation, where this sort of replacement can be more effective
in SSA form or by first applying copy propagation. Perhaps if the
coercion was explicit a CSE pass could even eliminate any duplicates.

Cheers,
Mark

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

From robertwb at gmail.com  Sun Jul  6 02:31:21 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Sat, 5 Jul 2014 17:31:21 -0700
Subject: [Cython] Travis-ci builds of OSX wheels
In-Reply-To: <CAH6Pt5qVKgiUb_Xvy9yHULjXwfQM3ztyd9eeWDAZtVJLSBkiDg@mail.gmail.com>
References: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
 <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>
 <CAH6Pt5qVKgiUb_Xvy9yHULjXwfQM3ztyd9eeWDAZtVJLSBkiDg@mail.gmail.com>
Message-ID: <CADiQ+QB+5szShbwE+npm1V=YctOmdk5Cecp38AX_Yoavcok1Mw@mail.gmail.com>

On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
>> Sure!
>>
>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> Hi,
>>>
>>> We just got scikit-image OSX wheel builds more or less fully automated
>>> on travis-ci :
>>>
>>> https://travis-ci.org/scikit-image/scikit-image-wheels
>>> https://github.com/scikit-image/scikit-image-wheels
>>>
>>> Any interest in getting the same thing working for Cython?
>>>
>>> Cheers,
>>>
>>> Matthew
>
> Done:
>
> https://github.com/matthew-brett/cython-wheels
> https://travis-ci.org/matthew-brett/cython-wheels
> http://wheels.scikit-image.org
>
> When y'all have permission, you should be able to click on the refresh
> button on the travis page and get built wheels in the http directory,
> after 20 minutes or so.  It's set up to checkout and build the latest
> tag'ed commit.
>
> Feel free to just clone this repo and push to the Cython organization.
> I can then send you a PR updating the rackspace credentials to match
> the new repo.

Forked at https://github.com/cython/cython-wheels

From matthew.brett at gmail.com  Sun Jul  6 03:27:56 2014
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sun, 6 Jul 2014 02:27:56 +0100
Subject: [Cython] Travis-ci builds of OSX wheels
In-Reply-To: <CADiQ+QB+5szShbwE+npm1V=YctOmdk5Cecp38AX_Yoavcok1Mw@mail.gmail.com>
References: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
 <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>
 <CAH6Pt5qVKgiUb_Xvy9yHULjXwfQM3ztyd9eeWDAZtVJLSBkiDg@mail.gmail.com>
 <CADiQ+QB+5szShbwE+npm1V=YctOmdk5Cecp38AX_Yoavcok1Mw@mail.gmail.com>
Message-ID: <CAH6Pt5oqaec_o9qfeqqD+TBkkVtZdsgxE+wS7-LP6zgM+ruZwQ@mail.gmail.com>

Hi,

On Sun, Jul 6, 2014 at 1:31 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
>>> Sure!
>>>
>>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> We just got scikit-image OSX wheel builds more or less fully automated
>>>> on travis-ci :
>>>>
>>>> https://travis-ci.org/scikit-image/scikit-image-wheels
>>>> https://github.com/scikit-image/scikit-image-wheels
>>>>
>>>> Any interest in getting the same thing working for Cython?
>>>>
>>>> Cheers,
>>>>
>>>> Matthew
>>
>> Done:
>>
>> https://github.com/matthew-brett/cython-wheels
>> https://travis-ci.org/matthew-brett/cython-wheels
>> http://wheels.scikit-image.org
>>
>> When y'all have permission, you should be able to click on the refresh
>> button on the travis page and get built wheels in the http directory,
>> after 20 minutes or so.  It's set up to checkout and build the latest
>> tag'ed commit.
>>
>> Feel free to just clone this repo and push to the Cython organization.
>> I can then send you a PR updating the rackspace credentials to match
>> the new repo.
>
> Forked at https://github.com/cython/cython-wheels

OK - then I will try deleting my repo and see what happens.

Can you activate travis testing for that repo?  Then I'll set the credentials.

Cheers,

Matthew

From robertwb at gmail.com  Sun Jul  6 03:37:43 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Sat, 5 Jul 2014 18:37:43 -0700
Subject: [Cython] Travis-ci builds of OSX wheels
In-Reply-To: <CAH6Pt5oqaec_o9qfeqqD+TBkkVtZdsgxE+wS7-LP6zgM+ruZwQ@mail.gmail.com>
References: <CAH6Pt5p6_ssB8eNcQoswvMa7q+AJN0_HEajonVq0NneUhEH2sQ@mail.gmail.com>
 <CADiQ+QBrR2RbFx_ZntCZ5neoQADcjCFHF5qFpyf+uhi9kCT5Ew@mail.gmail.com>
 <CAH6Pt5qVKgiUb_Xvy9yHULjXwfQM3ztyd9eeWDAZtVJLSBkiDg@mail.gmail.com>
 <CADiQ+QB+5szShbwE+npm1V=YctOmdk5Cecp38AX_Yoavcok1Mw@mail.gmail.com>
 <CAH6Pt5oqaec_o9qfeqqD+TBkkVtZdsgxE+wS7-LP6zgM+ruZwQ@mail.gmail.com>
Message-ID: <CADiQ+QCmg=c_ihA2dG154Vxz6R0FSWC7LQ2s3tWG23QDLk_fDA@mail.gmail.com>

On Sat, Jul 5, 2014 at 6:27 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Sun, Jul 6, 2014 at 1:31 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
>> On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
>>>> Sure!
>>>>
>>>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> We just got scikit-image OSX wheel builds more or less fully automated
>>>>> on travis-ci :
>>>>>
>>>>> https://travis-ci.org/scikit-image/scikit-image-wheels
>>>>> https://github.com/scikit-image/scikit-image-wheels
>>>>>
>>>>> Any interest in getting the same thing working for Cython?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Matthew
>>>
>>> Done:
>>>
>>> https://github.com/matthew-brett/cython-wheels
>>> https://travis-ci.org/matthew-brett/cython-wheels
>>> http://wheels.scikit-image.org
>>>
>>> When y'all have permission, you should be able to click on the refresh
>>> button on the travis page and get built wheels in the http directory,
>>> after 20 minutes or so.  It's set up to checkout and build the latest
>>> tag'ed commit.
>>>
>>> Feel free to just clone this repo and push to the Cython organization.
>>> I can then send you a PR updating the rackspace credentials to match
>>> the new repo.
>>
>> Forked at https://github.com/cython/cython-wheels
>
> OK - then I will try deleting my repo and see what happens.
>
> Can you activate travis testing for that repo?  Then I'll set the credentials.

Done.

From stefan_ml at behnel.de  Sun Jul  6 10:53:38 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 06 Jul 2014 10:53:38 +0200
Subject: [Cython] memory view creation during cascaded assignments
In-Reply-To: <CANg26EXiOO73D0-9qJWhNu=h6YbDEE9KKWTxK+7KnhnHTcs=bQ@mail.gmail.com>
References: <53B7D4C8.4070406@behnel.de>
 <CANg26EXiOO73D0-9qJWhNu=h6YbDEE9KKWTxK+7KnhnHTcs=bQ@mail.gmail.com>
Message-ID: <53B90E92.7000804@behnel.de>

Hi Mark!

Mark Florisson, 05.07.2014 14:49:
> On 5 July 2014 11:34, Stefan Behnel wrote:
>> I started optimising cascaded assignments a little to reduce the
>> unnecessary duplication of coercions.
>> It's explicitly tested for that we create two independent memory views in
>> this case. Is there an actual reason for this? As long as the types of a
>> and b are identical, I don't see why we would want to request the buffer twice.
> 
> I think it's mostly for simplicity, since any reaching definition is
> cleared at the end of the function. Are you thinking to generally
> implement this?

No, it just got in the way for cascaded assignments. For anything else, I
think users can just assign an existing memory view reference instead of
the original object if they need another variable. That's up to them, and
the difference should be obvious enough when you run into it.

Thanks for the quick answer, I'm happy that I don't have to add a special
case to my changes just for this.

Stefan


From stefan_ml at behnel.de  Mon Jul  7 00:38:22 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 07 Jul 2014 00:38:22 +0200
Subject: [Cython]
 =?utf-8?q?Wrong_order_of_=5F=5FPyx=5FDECREF_when_calling?=
 =?utf-8?q?_a_function_with_an_implicit_str_=E2=86=92_char*_conversion=2E?=
In-Reply-To: <20140528112547.GA2814@yuyuko>
References: <20140528112547.GA2814@yuyuko>
Message-ID: <53B9CFDE.1060500@behnel.de>

Emmanuel Gil Peyrot, 28.05.2014 13:25:
> I was testing my cython codebase on top of pypy/cpyext, and I found a
> memory corruption.  After investigating it with the pypy guys (thanks
> arigato!), we identified it as a cython bug:
> 
>  cdef void test(char *string):
>      print(string)
> 
>  def run(array):
>      test(array[0])
> 
> This code works fine under cpython, but looking at the generated code
> for the last line, the call to test is done with a pointer (__pyx_t_2)
> to some potentially deallocated string (__pyx_t_1), which isn?t freed
> just yet on cpython but is on pypy:
> 
>  __pyx_t_1 = __Pyx_GetItemInt(__pyx_v_array, 0, ?);
>  __Pyx_GOTREF(__pyx_t_1);
>  __pyx_t_2 = __Pyx_PyObject_AsString(__pyx_t_1);
>  __Pyx_DECREF(__pyx_t_1); __pyx_t_1 = 0;
>  __pyx_f_1a_test(__pyx_t_2);
> 
> 
> The obvious solution is to swap the last two lines, it then works fine
> on pypy (although not necessarily if the test function stores the
> pointer somewhere, but it?s not cython?s fault then).
> 
> This issue can also happen with an explicit cast:
> 
>  pointer = <char *>array[0]
>  test(pointer)

I pushed a fix for both cases here:

https://github.com/cython/cython/commit/37e4a20615c323b695bd2ec5db0dc20a25a4417f

There are still a couple of tests failing, but that should be fixable.

The change moves the compile time error to assignment time and postpones
the temp reference cleanup for char* inside of expressions. This makes
temporary char* handling generally safer, including passing it into
external functions (which, as you said, is safe as long as the user takes
the obvious bit of care to not store it beyond the call scope).

The only drawback is that this may keep temporary Python strings alive
longer than strictly necessary (and longer than before), but if that really
becomes a problem, it should be easy to work around by splitting up the
expressions.


> I?m not sure if it should be addressed the same way, because that would
> mean keeping a reference to array[0] for all the lifetime of the
> current scope, but it could still prevent obscure bugs like the memory
> corruption I had.

The generally assumption, and the reason why indexing is considered safer
than e.g. concatenation, is that indexing often returns a duplicated
reference to an object stored in a container. That does not necessarily
apply to PyPy's cpyext, but the change above should at least fix the
problem you found there.

Stefan


From gandalf013 at gmail.com  Wed Jul  9 01:34:53 2014
From: gandalf013 at gmail.com (Alok Singhal)
Date: Tue, 8 Jul 2014 16:34:53 -0700
Subject: [Cython] Compiler crash: forward declaration of cdef class with
	"public" attributes
Message-ID: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>

Hi,

I am getting a compiler crash with the following code:

$ cat foo.pxd
cdef class Foo:
    cdef public object x
$ cat foo.pyx
cdef class Foo

cdef class Foo:
    pass
$ ./cython.py  foo.pyx

Error compiling Cython file:
------------------------------------------------------------
...
cdef class Foo
    ^
------------------------------------------------------------

foo.pyx:1:5: Compiler crash in AnalyseDeclarationsTransform

ModuleNode.body = StatListNode(foo.pyx:1:0)
StatListNode.stats[0] = CClassDefNode(foo.pyx:1:5,
    as_name = u'Foo',
    class_name = u'Foo',
    module_name = '',
    visibility = 'private')

Compiler crash traceback from this point on:
  File "/Users/alok/Downloads/repos/cython.git/Cython/Compiler/Visitor.py",
line 173, in _visit
    return handler_method(obj)
  File
"/Users/alok/Downloads/repos/cython.git/Cython/Compiler/ParseTreeTransforms.py",
line 1478, in visit_CClassDefNode
    node.body.stats += stats
AttributeError: 'NoneType' object has no attribute 'stats'

The problem seems to be due to having a .pxd file with the attributes of
the cdef class in it.  Since the attributes are declared "public", Cython
is trying to generate property code for "Foo.x".  But it's trying to do
that at the point of forward declaration in the .pyx file, instead of the
definition of the class.

An easy fix seems to be to change
AnalyseDeclarationsTransform.visit_CClassDefNode in ParseTreeTransforms.py
to check for node.body not being none.  I.e., the following patch seems to
work:

diff --git a/Cython/Compiler/ParseTreeTransforms.py
b/Cython/Compiler/ParseTreeTransforms.py
index f8c2efa..7811d56 100644
--- a/Cython/Compiler/ParseTreeTransforms.py
+++ b/Cython/Compiler/ParseTreeTransforms.py
@@ -1466,7 +1466,7 @@ if VALUE is not None:

     def visit_CClassDefNode(self, node):
         node = self.visit_ClassDefNode(node)
-        if node.scope and node.scope.implemented:
+        if node.body and node.scope and node.scope.implemented:
             stats = []
             for entry in node.scope.var_entries:
                 if entry.needs_property:

Thanks,
Alok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140708/a6079e4e/attachment.html>

From stefan_ml at behnel.de  Mon Jul 14 21:49:28 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 14 Jul 2014 21:49:28 +0200
Subject: [Cython] heads-up on master branch status
Message-ID: <53C43448.8060102@behnel.de>

Hi,

by applying some initially small but perpetually growing fixes, I pushed
myself into a corner where the only escape was to rewrite BoolBinopNode
(short-circuiting and/or expressions). This was long overdue anyway and
simply wasn't done before because it's not trivial and quite risky. I think
I got it working better than before, but there are still corner cases that
require some further fighting. One of them currently crashes the pyregr
tests in Py2.7, it's this code:

    [tuple((e is None and 'X' or e) for e in t) for t in target]

Thank you, python-devs, for collecting these little gems in the test suite.
>From the C code this generates, the problem seems to be related to type
coercion in closures. I'm currently preparing my participation at
EuroPython next week, so I can't tell for sure when I'll be able to dig
into this. This means that current master may stay less stable than it
should be for a couple of more days.

Stefan

From robertwb at gmail.com  Tue Jul 15 23:13:38 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Tue, 15 Jul 2014 14:13:38 -0700
Subject: [Cython] heads-up on master branch status
In-Reply-To: <53C43448.8060102@behnel.de>
References: <53C43448.8060102@behnel.de>
Message-ID: <CADiQ+QD3_Y4+Vx5t3hBne5sAc+NfYSbr2GeupzdQM5h+vJTGyQ@mail.gmail.com>

Ironically, I noticed these BoolBinop failures and started working on a fix
myself (including side diversions like making void* the spanning type of
all pointers) before noticing that you were on it, so I have a bit of an
idea what a long, twisty path this starts down and can only say thanks for
taking this on.

- Robert



On Mon, Jul 14, 2014 at 12:49 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Hi,
>
> by applying some initially small but perpetually growing fixes, I pushed
> myself into a corner where the only escape was to rewrite BoolBinopNode
> (short-circuiting and/or expressions). This was long overdue anyway and
> simply wasn't done before because it's not trivial and quite risky. I think
> I got it working better than before, but there are still corner cases that
> require some further fighting. One of them currently crashes the pyregr
> tests in Py2.7, it's this code:
>
>     [tuple((e is None and 'X' or e) for e in t) for t in target]
>
> Thank you, python-devs, for collecting these little gems in the test suite.
> From the C code this generates, the problem seems to be related to type
> coercion in closures. I'm currently preparing my participation at
> EuroPython next week, so I can't tell for sure when I'll be able to dig
> into this. This means that current master may stay less stable than it
> should be for a couple of more days.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140715/0af2a422/attachment.html>

From qsr at chromium.org  Tue Jul 15 11:12:16 2014
From: qsr at chromium.org (Benjamin Lerman)
Date: Tue, 15 Jul 2014 11:12:16 +0200
Subject: [Cython] License information on each individual files
Message-ID: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>

 Hi,

 I'm planning to use cython in chromium.

 To be able to use cython as a third-party library, we need a license
header on every files in the project (because we are creating source
packages, and need to have clear licensing).

 Would cython accept to add such a copyright header on its files?

 Thanks in advance,

-- 
        Benjamin

From kwmsmith at gmail.com  Wed Jul 16 19:01:50 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Wed, 16 Jul 2014 12:01:50 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
Message-ID: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>

Hi devs,

Being able to convert between simple C structs and Python dictionaries is
great, but it doesn't work if there is a fixed-size array field in the
struct.  It seems like the following struct should be convertible safely:

cdef struct state_t:
    int i, j, k
    float x[3]
    float v[3]

Along with that, I'd expect that converting between fixed-sized C arrays
and Python iterables should work as well:

def auto_convert(list ll):
    cdef int arr[10] = ll
    # ...
    return arr

If this is deemed something worth doing and if someone is willing to give
pointers when I get stuck, I'm offering to put in the development time to
implement this.

Thoughts?

Kurt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140716/221589eb/attachment.html>

From robertwb at gmail.com  Wed Jul 16 20:02:13 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 16 Jul 2014 11:02:13 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
Message-ID: <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>

On Wed, Jul 16, 2014 at 10:01 AM, Kurt Smith <kwmsmith at gmail.com> wrote:
> Hi devs,
>
> Being able to convert between simple C structs and Python dictionaries is
> great, but it doesn't work if there is a fixed-size array field in the
> struct.  It seems like the following struct should be convertible safely:
>
> cdef struct state_t:
>     int i, j, k
>     float x[3]
>     float v[3]
>
> Along with that, I'd expect that converting between fixed-sized C arrays and
> Python iterables should work as well:
>
> def auto_convert(list ll):
>     cdef int arr[10] = ll
>     # ...
>     return arr
>
> If this is deemed something worth doing and if someone is willing to give
> pointers when I get stuck, I'm offering to put in the development time to
> implement this.
>
> Thoughts?

Yes, this'd be nice to have. One difficulty with arrays is that they
can't be returned by value, and so the ordinary from_py_function
mechanism (which gets called recursively) would need to be adapted.
(Allowing to_py_function to be optinally be called by reference
instead of by value could be nice as well from a performance
standpoint.)

- Robert

From kwmsmith at gmail.com  Fri Jul 18 21:08:50 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Fri, 18 Jul 2014 14:08:50 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
Message-ID: <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>

On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>
>
> Yes, this'd be nice to have. One difficulty with arrays is that they
> can't be returned by value, and so the ordinary from_py_function
> mechanism (which gets called recursively) would need to be adapted.
> (Allowing to_py_function to be optinally be called by reference
> instead of by value could be nice as well from a performance
> standpoint.)
>

OK, thanks for the pointers.  I'll put some time on this over the weekend.
 Should I just make a PR when things are ready to review, or should I put
up an issue first?


>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140718/5255b1cb/attachment.html>

From robertwb at gmail.com  Fri Jul 18 21:44:47 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 18 Jul 2014 12:44:47 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
Message-ID: <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>

On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>>
>>
>> Yes, this'd be nice to have. One difficulty with arrays is that they
>> can't be returned by value, and so the ordinary from_py_function
>> mechanism (which gets called recursively) would need to be adapted.
>> (Allowing to_py_function to be optinally be called by reference
>> instead of by value could be nice as well from a performance
>> standpoint.)
>
>
> OK, thanks for the pointers.  I'll put some time on this over the weekend.
> Should I just make a PR when things are ready to review, or should I put up
> an issue first?

I think this thread is sufficient; looking forward to a pull request.

- Robert

From sturla.molden at gmail.com  Fri Jul 18 23:13:55 2014
From: sturla.molden at gmail.com (Sturla Molden)
Date: Fri, 18 Jul 2014 21:13:55 +0000 (UTC)
Subject: [Cython] License information on each individual files
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
Message-ID: <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>

Benjamin Lerman <qsr at chromium.org> wrote:

>  Would cython accept to add such a copyright header on its files?

You want to display the Apache licence in every single file, even those
with utility C code?

Can't you do this in your own copy of Cython? I am quite sure the license
allows you to modify the source files (almost) however you like.

What do you do with other Python projects which do not put copyright
notices everywhere?

Have you considered to get rid of the lawyer who makes these stupid
requests?

Just asking...


Sturla


From njs at pobox.com  Fri Jul 18 23:28:59 2014
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 18 Jul 2014 22:28:59 +0100
Subject: [Cython] License information on each individual files
In-Reply-To: <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
Message-ID: <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>

On Fri, Jul 18, 2014 at 10:13 PM, Sturla Molden <sturla.molden at gmail.com> wrote:
> Benjamin Lerman <qsr at chromium.org> wrote:
>
>>  Would cython accept to add such a copyright header on its files?
>
> You want to display the Apache licence in every single file, even those
> with utility C code?

It's annoying, but a pretty standard request. Debian once made me do
this for some package or another (forget which) before they would
distribute it, though obviously that rule is inconsistently applied.
Still, it's pretty trivial and has real-world consequences, so why
reject a patch like this?

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

From robertwb at gmail.com  Fri Jul 18 23:53:48 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 18 Jul 2014 14:53:48 -0700
Subject: [Cython] License information on each individual files
In-Reply-To: <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
Message-ID: <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>

On Fri, Jul 18, 2014 at 2:28 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Jul 18, 2014 at 10:13 PM, Sturla Molden <sturla.molden at gmail.com>
> wrote:
> > Benjamin Lerman <qsr at chromium.org> wrote:
> >
> >>  Would cython accept to add such a copyright header on its files?
> >
> > You want to display the Apache licence in every single file, even those
> > with utility C code?
>
> It's annoying, but a pretty standard request. Debian once made me do
> this for some package or another (forget which) before they would
> distribute it, though obviously that rule is inconsistently applied.
> Still, it's pretty trivial and has real-world consequences, so why
> reject a patch like this?


Debian currently distributes Cython without these headers.

I am curious why a licence in a top level directory that explicitly states
it applies to everything in that directory is not sufficiently clear. What
about auto-generated files? What about binary blobs? All 1000+ test files?

http://www.apache.org/dev/apply-license.html#copy-per-file

- Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140718/3bb1e09e/attachment.html>

From njs at pobox.com  Sat Jul 19 00:12:56 2014
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 18 Jul 2014 23:12:56 +0100
Subject: [Cython] License information on each individual files
In-Reply-To: <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
Message-ID: <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>

On Fri, Jul 18, 2014 at 10:53 PM, Robert Bradshaw <robertwb at gmail.com>
wrote:

> On Fri, Jul 18, 2014 at 2:28 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Fri, Jul 18, 2014 at 10:13 PM, Sturla Molden <sturla.molden at gmail.com>
>> wrote:
>> > Benjamin Lerman <qsr at chromium.org> wrote:
>> >
>> >>  Would cython accept to add such a copyright header on its files?
>> >
>> > You want to display the Apache licence in every single file, even those
>> > with utility C code?
>>
>> It's annoying, but a pretty standard request. Debian once made me do
>> this for some package or another (forget which) before they would
>> distribute it, though obviously that rule is inconsistently applied.
>> Still, it's pretty trivial and has real-world consequences, so why
>> reject a patch like this?
>
>
> Debian currently distributes Cython without these headers.
>

Yes, they're inconsistent, as I noted.


>
> I am curious why a licence in a top level directory that explicitly states
> it applies to everything in that directory is not sufficiently clear. What
> about auto-generated files? What about binary blobs? All 1000+ test files?
>
> http://www.apache.org/dev/apply-license.html#copy-per-file
>

That link is about sticking a copy of the apache license text in every
file, this is about having a few line header saying "This is part of
Cython, copyright Cython devs, released under Apache-2, see LICENSE.txt for
details".

I'm just saying, you can argue about how chromium's lawyers ought to think,
or you can just say "whatever, patches welcome" and merge it if it arrives.
Your time is yours to spend as you wish :-) I was also very annoyed
initially when asked to do this, so thought I'd share my experience in case
it was useful.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140718/b6a1ceb9/attachment-0001.html>

From jtaylor.debian at googlemail.com  Sat Jul 19 00:24:06 2014
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Sat, 19 Jul 2014 00:24:06 +0200
Subject: [Cython] License information on each individual files
In-Reply-To: <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
Message-ID: <53C99E86.6010905@googlemail.com>

On 19.07.2014 00:12, Nathaniel Smith wrote:
> On Fri, Jul 18, 2014 at 10:53 PM, Robert Bradshaw <robertwb at gmail.com
> <mailto:robertwb at gmail.com>> wrote:
> 
>     On Fri, Jul 18, 2014 at 2:28 PM, Nathaniel Smith <njs at pobox.com
>     <mailto:njs at pobox.com>> wrote:
> 
>         On Fri, Jul 18, 2014 at 10:13 PM, Sturla Molden
>         <sturla.molden at gmail.com <mailto:sturla.molden at gmail.com>> wrote:
>         > Benjamin Lerman <qsr at chromium.org <mailto:qsr at chromium.org>>
>         wrote:
>         >
>         >>  Would cython accept to add such a copyright header on its files?
>         >
>         > You want to display the Apache licence in every single file,
>         even those
>         > with utility C code?
> 
>         It's annoying, but a pretty standard request. Debian once made me do
>         this for some package or another (forget which) before they would
>         distribute it, though obviously that rule is inconsistently applied.
>         Still, it's pretty trivial and has real-world consequences, so why
>         reject a patch like this?
> 
> 
>     Debian currently distributes Cython without these headers. 
> 
> 
> Yes, they're inconsistent, as I noted.
>  

It is inconsistent but still encouraged.
As a debian maintainer I much appreciate when the files all contain
copyright statements, it simplifies one of the most time consuming part
of packaging, making sure all the copyrights are in order.
Per file copyright headers allow automated tools to quickly classify a
source tree and make it easier to find the files that need more detailed
checking.


> 
> 
>     I am curious why a licence in a top level directory that explicitly
>     states it applies to everything in that directory is not
>     sufficiently clear. What about auto-generated files? What about
>     binary blobs? All 1000+ test files? 
> 
>     http://www.apache.org/dev/apply-license.html#copy-per-file
> 
> 
> That link is about sticking a copy of the apache license text in every
> file, this is about having a few line header saying "This is part of
> Cython, copyright Cython devs, released under Apache-2, see LICENSE.txt
> for details".

Yes you only need to include a short header not the full license.
The recommended header is in the APPENDIX section:
http://www.apache.org/licenses/LICENSE-2.0

From robertwb at gmail.com  Sat Jul 19 00:26:11 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 18 Jul 2014 15:26:11 -0700
Subject: [Cython] License information on each individual files
In-Reply-To: <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
Message-ID: <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>

On Fri, Jul 18, 2014 at 3:12 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Jul 18, 2014 at 10:53 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
>
>> On Fri, Jul 18, 2014 at 2:28 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>
>>> On Fri, Jul 18, 2014 at 10:13 PM, Sturla Molden <sturla.molden at gmail.com>
>>> wrote:
>>> > Benjamin Lerman <qsr at chromium.org> wrote:
>>> >
>>> >>  Would cython accept to add such a copyright header on its files?
>>> >
>>> > You want to display the Apache licence in every single file, even those
>>> > with utility C code?
>>>
>>> It's annoying, but a pretty standard request. Debian once made me do
>>> this for some package or another (forget which) before they would
>>> distribute it, though obviously that rule is inconsistently applied.
>>> Still, it's pretty trivial and has real-world consequences, so why
>>> reject a patch like this?
>>
>>
>> Debian currently distributes Cython without these headers.
>>
>
> Yes, they're inconsistent, as I noted.
>
>
>>
>> I am curious why a licence in a top level directory that explicitly
>> states it applies to everything in that directory is not sufficiently
>> clear. What about auto-generated files? What about binary blobs? All 1000+
>> test files?
>>
>> http://www.apache.org/dev/apply-license.html#copy-per-file
>>
>
> That link is about sticking a copy of the apache license text in every
> file, this is about having a few line header saying "This is part of
> Cython, copyright Cython devs, released under Apache-2, see LICENSE.txt for
> details".
>
> I'm just saying, you can argue about how chromium's lawyers ought to
> think, or you can just say "whatever, patches welcome" and merge it if it
> arrives. Your time is yours to spend as you wish :-) I was also very
> annoyed initially when asked to do this, so thought I'd share my experience
> in case it was useful.
>

It's not just the initial patch; I'm primarily worried about the
maintenance burden. For example, either we require (and enforce) it on all
new files or you get into this inconsistent state where some files have a
statement and some don't, and it's unclear what the copyright implications
of this inconsistency is. And that's assuming we don't have to mess with
years, author lists, etc. (not clear what the request was).

There's plenty of precedent for not tagging every file (e.g. the linux
kernel).

- Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140718/264cc133/attachment.html>

From sturla.molden at gmail.com  Sat Jul 19 00:36:21 2014
From: sturla.molden at gmail.com (Sturla Molden)
Date: Fri, 18 Jul 2014 22:36:21 +0000 (UTC)
Subject: [Cython] License information on each individual files
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
 <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>
Message-ID: <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>

Robert Bradshaw <robertwb at gmail.com> wrote:

> It's not just the initial patch; I'm primarily worried about the
> maintenance burden

And also, will it break utility code and binary blobs? It might not even be
safe to put it in every file.

And when put in files with utility C code, will it be included in the
generated .c file and taint this file with a notification about Cython's
Apache license?

Sturla


From stefan_ml at behnel.de  Sat Jul 19 08:39:36 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 19 Jul 2014 08:39:36 +0200
Subject: [Cython] License information on each individual files
In-Reply-To: <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
 <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>
 <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>
Message-ID: <53CA12A8.5020606@behnel.de>

Sturla Molden, 19.07.2014 00:36:
> Robert Bradshaw wrote:
>> It's not just the initial patch; I'm primarily worried about the
>> maintenance burden
> 
> And also, will it break utility code and binary blobs? It might not even be
> safe to put it in every file.
> 
> And when put in files with utility C code, will it be included in the
> generated .c file and taint this file with a notification about Cython's
> Apache license?

Well, on the technical side, stuff at the beginning of a utility code file
should just be ignored, up to the first header line (starting with a
sequence of at least 5 comment characters). Some of them already contain
leading comments anyway.

On the legal side, the licensing state of the generated code does not
change by copying the license description from the global license file into
each code file, because the global license already applies to the complete
code base anyway (unless stated otherwise).

However, what *is* the licensing state of the generated code? Strictly
speaking, the code generated by Cython, all parts of which are embedded in
Cython's own source code, could be considered a "derivative work" by some.
The Apache license states this regarding "redistribution of derivative works":


"""
   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, [does not apply].

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.
"""

There was an official statement of the core devs back in 2007 that the
generated code is free of restrictions, but it was based on the Python
License at the time and I also don't think it's expressed in the code base
anywhere.

http://thread.gmane.org/gmane.comp.python.cython.devel/117

http://article.gmane.org/gmane.comp.python.cython.devel/122

>From my side, that statement definitely still applies. I really don't want
to have anything to say on what users do with the code generated from their
own source code. I do not even consider the generated code a "derivative
work" myself, but IANAL...

Anyway, as far as I understand it, the worst case is that people who ship
Cython generated code have to add a copy of the Apache License to their
package as well as any attribution notices we ship. That's annoying, but
not really the end of the world.

Also, utility code files could be exempt from the license explicitly by
stating so (although they'd then need another license to allow for safe
contributions to them). AFAICT, there were some twenty people or so who
ever contributed to the Cython/Utility directory and less than ten people
who ever changed or added a notable amount of code in them. That might be
worth it, given that it's difficult enough to argue that the rest of the
generated code, which gets created (and substantially modified along the
way) from tiny snippets in another code base (so tiny that none of them
could ever be considered a protectable piece of work by itself) falls under
any "derivative work" licensing terms at all. And any substantial (i.e.
protectable) portion of these snippets was written by one of seven people
or so.

Therefore, adding the license header explicitly to all files that really
fall under that license, and exclude the utility code files while doing so,
actually sounds like a good idea.


Stefan


From njs at pobox.com  Sat Jul 19 19:42:20 2014
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 19 Jul 2014 18:42:20 +0100
Subject: [Cython] License information on each individual files
In-Reply-To: <53CA12A8.5020606@behnel.de>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
 <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>
 <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>
 <53CA12A8.5020606@behnel.de>
Message-ID: <CAPJVwB=na8H8250r2eWevPXt5HRF4ODwTHhiUZtv4XsFkcHaQQ@mail.gmail.com>

On Sat, Jul 19, 2014 at 7:39 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>
> Sturla Molden, 19.07.2014 00:36:
> > Robert Bradshaw wrote:
> >> It's not just the initial patch; I'm primarily worried about the
> >> maintenance burden
> >
> > And also, will it break utility code and binary blobs? It might not even be
> > safe to put it in every file.
> >
> > And when put in files with utility C code, will it be included in the
> > generated .c file and taint this file with a notification about Cython's
> > Apache license?
>
> Well, on the technical side, stuff at the beginning of a utility code file
> should just be ignored, up to the first header line (starting with a
> sequence of at least 5 comment characters). Some of them already contain
> leading comments anyway.
>
> On the legal side, the licensing state of the generated code does not
> change by copying the license description from the global license file into
> each code file, because the global license already applies to the complete
> code base anyway (unless stated otherwise).
>
> However, what *is* the licensing state of the generated code? Strictly
> speaking, the code generated by Cython, all parts of which are embedded in
> Cython's own source code, could be considered a "derivative work" by some.

I suspect that "some" includes most lawyers and judges ;-). There's
tons of copyrightable code copied into Cython output.

[...]
> From my side, that statement definitely still applies. I really don't want
> to have anything to say on what users do with the code generated from their
> own source code. I do not even consider the generated code a "derivative
> work" myself, but IANAL...
>
> Anyway, as far as I understand it, the worst case is that people who ship
> Cython generated code have to add a copy of the Apache License to their
> package as well as any attribution notices we ship. That's annoying, but
> not really the end of the world.

No, the worst case is that GPL2 projects can't legally use code
written in Cython (perhaps even indirectly via other projects) :-(.
This might be okay because of the language in the GPL that's designed
to make it possible to write e.g. GPL'ed Win32 programs, but I'm not
at all sure.

> Also, utility code files could be exempt from the license explicitly by
> stating so (although they'd then need another license to allow for safe
> contributions to them).

There's substantial prior art for this kind of thing, see e.g. the GCC
runtime exception, the Classpath exception, etc.

You might want to send an email to help at softwarefreedom.org describing
the situation and asking for advice. (See
https://www.softwarefreedom.org/about/contact/)

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

From lists at onerussian.com  Sun Jul 20 06:39:39 2014
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Sun, 20 Jul 2014 00:39:39 -0400
Subject: [Cython] Cython bugfix release
In-Reply-To: <20140619152810.GC8748@onerussian.com>
References: <CADiQ+QAbqG+iXHp030EBpds4qZOKojM5Ypp7r8Ks-ZdmzZwSxw@mail.gmail.com>
 <20140618153740.GA8748@onerussian.com>
 <20140619152810.GC8748@onerussian.com>
Message-ID: <20140720043939.GT8748@onerussian.com>

that was quite an underwhelming response,  now it is "official"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340
and I haven't had yet a chance to recheck master... anyone has a clue
before I start digging?

On Thu, 19 Jun 2014, Yaroslav Halchenko wrote:

> and the same issue in current(ish) master:

> ======================================================================
> ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py", line 280, in test_all
>     sys.stderr.write(errmsg)
> UnicodeEncodeError: 'ascii' codec can't encode characters in position 21001-21004: ordinal not in range(128)

> ----------------------------------------------------------------------
> Ran 8348 tests in 2674.102s



> On Wed, 18 Jun 2014, Yaroslav Halchenko wrote:

> > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be available
> > to Debian folks soon too

> > while trying 0.20.1 across debian/ubuntus I ran into this failure

> > ======================================================================
> > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py", line 281, in test_all
> >     sys.stderr.write(errmsg)
> > UnicodeEncodeError: 'ascii' codec can't encode characters in position 18851-18854: ordinal not in range(128)

> > on debian wheezy i386.  it didn't happen on amd64 and on both architectures
> > under debian jessie (testing) and it seemed to happen while testing with
> > python2.6 

> > On Mon, 16 Jun 2014, Robert Bradshaw wrote:

> > > I just pushed another bugfix release for the 0.20.x line, available on
> > > github, cython.org, or and pypi.

> > > == Features added ==

> > > * Some optimisations for set/frozenset instantiation.
> > > * Support for C++ unordered_set and unordered_map.

> > > == Bugs fixed ==

> > > * Access to attributes of optimised builtin methods (e.g.
> > > [].append.__name__) could fail to compile.
> > > * Memory leak when extension subtypes add a memory view as attribute
> > > to those of the parent type without having Python object attributes or
> > > a user provided dealloc method.
> > > * Compiler crash on readonly properties in "binding" mode.
> > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3.
> > > * Crash when subtyping freelist enabled Cython extension types with
> > > Python classes that use __slots__.
> > > * Freelist usage is restricted to CPython to avoid problems with other
> > > Python implementations.
> > > * Memory leak in memory views when copying overlapping, contiguous slices.
> > > * Format checking when requesting non-contiguous buffers from
> > > cython.array objects was disabled in Py3.
> > > * C++ destructor calls in extension types could fail to compile in clang.
> > > * Buffer format validation failed for sequences of strings in structs.
> > > * Docstrings on extension type attributes in .pxd files were rejected.

> > > == Contributors ==

> > > Andreas van Cranenburgh
> > > Ian Bell
> > > Lars Buitinck
> > > Martin Quarda
> > > Mikhail Korobov
> > > Robert Bradshaw
> > > Stefan Behnel
> > > _______________________________________________
> > > cython-devel mailing list
> > > cython-devel at python.org
> > > https://mail.python.org/mailman/listinfo/cython-devel
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

From stefan_ml at behnel.de  Sun Jul 20 09:37:17 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Jul 2014 09:37:17 +0200
Subject: [Cython] License information on each individual files
In-Reply-To: <CAPJVwB=na8H8250r2eWevPXt5HRF4ODwTHhiUZtv4XsFkcHaQQ@mail.gmail.com>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
 <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>
 <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>
 <53CA12A8.5020606@behnel.de>
 <CAPJVwB=na8H8250r2eWevPXt5HRF4ODwTHhiUZtv4XsFkcHaQQ@mail.gmail.com>
Message-ID: <53CB71AD.9040805@behnel.de>

Nathaniel Smith, 19.07.2014 19:42:
> On Sat, Jul 19, 2014 at 7:39 AM, Stefan Behnel wrote:
>> Sturla Molden, 19.07.2014 00:36:
>>> Robert Bradshaw wrote:
>>>> It's not just the initial patch; I'm primarily worried about the
>>>> maintenance burden
>>>
>>> And also, will it break utility code and binary blobs? It might not even be
>>> safe to put it in every file.
>>>
>>> And when put in files with utility C code, will it be included in the
>>> generated .c file and taint this file with a notification about Cython's
>>> Apache license?
>>
>> Well, on the technical side, stuff at the beginning of a utility code file
>> should just be ignored, up to the first header line (starting with a
>> sequence of at least 5 comment characters). Some of them already contain
>> leading comments anyway.
>>
>> On the legal side, the licensing state of the generated code does not
>> change by copying the license description from the global license file into
>> each code file, because the global license already applies to the complete
>> code base anyway (unless stated otherwise).
>>
>> However, what *is* the licensing state of the generated code? Strictly
>> speaking, the code generated by Cython, all parts of which are embedded in
>> Cython's own source code, could be considered a "derivative work" by some.
> 
> I suspect that "some" includes most lawyers and judges ;-). There's
> tons of copyrightable code copied into Cython output.

The bulk of what gets "copied" are really just tiny character sequences
each of which would be impossible to protect legally. And they even get
substantially modified before being written out. But there's probably still
plenty of room for lawyers to sell days of work here, and the utility code
files form a major piece of work by themselves that gets copied into the
generated code in substantial (i.e. protectable) chunks.


>> From my side, that statement definitely still applies. I really don't want
>> to have anything to say on what users do with the code generated from their
>> own source code. I do not even consider the generated code a "derivative
>> work" myself, but IANAL...
>>
>> Anyway, as far as I understand it, the worst case is that people who ship
>> Cython generated code have to add a copy of the Apache License to their
>> package as well as any attribution notices we ship. That's annoying, but
>> not really the end of the world.
> 
> No, the worst case is that GPL2 projects can't legally use code
> written in Cython (perhaps even indirectly via other projects) :-(.

Interesting:

https://www.apache.org/licenses/GPL-compatibility.html

I wasn't aware of that problem, but now that I read about it, it's not
really a surprise.


>> Also, utility code files could be exempt from the license explicitly by
>> stating so (although they'd then need another license to allow for safe
>> contributions to them).
> 
> There's substantial prior art for this kind of thing, see e.g. the GCC
> runtime exception, the Classpath exception, etc.
> 
> You might want to send an email to help at softwarefreedom.org describing
> the situation and asking for advice. (See
> https://www.softwarefreedom.org/about/contact/)

Thanks for the pointer. Since it's a legal issue, it's usually best to
leave it to those who know their way around in that well minded area.

Stefan


From robertwb at gmail.com  Mon Jul 21 19:46:50 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Mon, 21 Jul 2014 10:46:50 -0700
Subject: [Cython] Cython bugfix release
In-Reply-To: <20140720043939.GT8748@onerussian.com>
References: <CADiQ+QAbqG+iXHp030EBpds4qZOKojM5Ypp7r8Ks-ZdmzZwSxw@mail.gmail.com>
 <20140618153740.GA8748@onerussian.com> <20140619152810.GC8748@onerussian.com>
 <20140720043939.GT8748@onerussian.com>
Message-ID: <CADiQ+QDOF701kAxuiUyH03dF7LQkuMJj=011hes7t2suuDDFMw@mail.gmail.com>

I wasn't able to reproduce this myself, which is why I haven't done
anything about it yet...


On Sat, Jul 19, 2014 at 9:39 PM, Yaroslav Halchenko <lists at onerussian.com>
wrote:

> that was quite an underwhelming response,  now it is "official"
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340
> and I haven't had yet a chance to recheck master... anyone has a clue
> before I start digging?
>
> On Thu, 19 Jun 2014, Yaroslav Halchenko wrote:
>
> > and the same issue in current(ish) master:
>
> > ======================================================================
> > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File
> "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py",
> line 280, in test_all
> >     sys.stderr.write(errmsg)
> > UnicodeEncodeError: 'ascii' codec can't encode characters in position
> 21001-21004: ordinal not in range(128)
>
> > ----------------------------------------------------------------------
> > Ran 8348 tests in 2674.102s
>
>
>
> > On Wed, 18 Jun 2014, Yaroslav Halchenko wrote:
>
> > > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be
> available
> > > to Debian folks soon too
>
> > > while trying 0.20.1 across debian/ubuntus I ran into this failure
>
> > > ======================================================================
> > > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> > > ----------------------------------------------------------------------
> > > Traceback (most recent call last):
> > >   File
> "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py", line
> 281, in test_all
> > >     sys.stderr.write(errmsg)
> > > UnicodeEncodeError: 'ascii' codec can't encode characters in position
> 18851-18854: ordinal not in range(128)
>
> > > on debian wheezy i386.  it didn't happen on amd64 and on both
> architectures
> > > under debian jessie (testing) and it seemed to happen while testing
> with
> > > python2.6
>
> > > On Mon, 16 Jun 2014, Robert Bradshaw wrote:
>
> > > > I just pushed another bugfix release for the 0.20.x line, available
> on
> > > > github, cython.org, or and pypi.
>
> > > > == Features added ==
>
> > > > * Some optimisations for set/frozenset instantiation.
> > > > * Support for C++ unordered_set and unordered_map.
>
> > > > == Bugs fixed ==
>
> > > > * Access to attributes of optimised builtin methods (e.g.
> > > > [].append.__name__) could fail to compile.
> > > > * Memory leak when extension subtypes add a memory view as attribute
> > > > to those of the parent type without having Python object attributes
> or
> > > > a user provided dealloc method.
> > > > * Compiler crash on readonly properties in "binding" mode.
> > > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3.
> > > > * Crash when subtyping freelist enabled Cython extension types with
> > > > Python classes that use __slots__.
> > > > * Freelist usage is restricted to CPython to avoid problems with
> other
> > > > Python implementations.
> > > > * Memory leak in memory views when copying overlapping, contiguous
> slices.
> > > > * Format checking when requesting non-contiguous buffers from
> > > > cython.array objects was disabled in Py3.
> > > > * C++ destructor calls in extension types could fail to compile in
> clang.
> > > > * Buffer format validation failed for sequences of strings in
> structs.
> > > > * Docstrings on extension type attributes in .pxd files were
> rejected.
>
> > > > == Contributors ==
>
> > > > Andreas van Cranenburgh
> > > > Ian Bell
> > > > Lars Buitinck
> > > > Martin Quarda
> > > > Mikhail Korobov
> > > > Robert Bradshaw
> > > > Stefan Behnel
> > > > _______________________________________________
> > > > cython-devel mailing list
> > > > cython-devel at python.org
> > > > https://mail.python.org/mailman/listinfo/cython-devel
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Research Scientist,            Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
> WWW:   http://www.linkedin.com/in/yarik
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140721/076b7e00/attachment.html>

From jtaylor.debian at googlemail.com  Mon Jul 21 20:51:29 2014
From: jtaylor.debian at googlemail.com (Julian Taylor)
Date: Mon, 21 Jul 2014 20:51:29 +0200
Subject: [Cython] Cython bugfix release
In-Reply-To: <CADiQ+QDOF701kAxuiUyH03dF7LQkuMJj=011hes7t2suuDDFMw@mail.gmail.com>
References: <CADiQ+QAbqG+iXHp030EBpds4qZOKojM5Ypp7r8Ks-ZdmzZwSxw@mail.gmail.com>
 <20140618153740.GA8748@onerussian.com> <20140619152810.GC8748@onerussian.com>
 <20140720043939.GT8748@onerussian.com>
 <CADiQ+QDOF701kAxuiUyH03dF7LQkuMJj=011hes7t2suuDDFMw@mail.gmail.com>
Message-ID: <53CD6131.9080700@googlemail.com>

I haven't tried it but its possibly related to the C locale the debian
builders use. Try with LC_ALL=C

@Yaroslav if this the the case, the workaround would be building with
LC_ALL=C.UTF-8

On 21.07.2014 19:46, Robert Bradshaw wrote:
> I wasn't able to reproduce this myself, which is why I haven't done
> anything about it yet...
> 
> 
> On Sat, Jul 19, 2014 at 9:39 PM, Yaroslav Halchenko
> <lists at onerussian.com <mailto:lists at onerussian.com>> wrote:
> 
>     that was quite an underwhelming response,  now it is "official"
>     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340
>     and I haven't had yet a chance to recheck master... anyone has a clue
>     before I start digging?
> 
>     On Thu, 19 Jun 2014, Yaroslav Halchenko wrote:
> 
>     > and the same issue in current(ish) master:
> 
>     > ======================================================================
>     > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
>     > ----------------------------------------------------------------------
>     > Traceback (most recent call last):
>     >   File
>     "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py",
>     line 280, in test_all
>     >     sys.stderr.write(errmsg)
>     > UnicodeEncodeError: 'ascii' codec can't encode characters in
>     position 21001-21004: ordinal not in range(128)
> 
>     > ----------------------------------------------------------------------
>     > Ran 8348 tests in 2674.102s
> 
> 
> 
>     > On Wed, 18 Jun 2014, Yaroslav Halchenko wrote:
> 
>     > > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be
>     available
>     > > to Debian folks soon too
> 
>     > > while trying 0.20.1 across debian/ubuntus I ran into this failure
> 
>     > >
>     ======================================================================
>     > > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
>     > >
>     ----------------------------------------------------------------------
>     > > Traceback (most recent call last):
>     > >   File
>     "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py",
>     line 281, in test_all
>     > >     sys.stderr.write(errmsg)
>     > > UnicodeEncodeError: 'ascii' codec can't encode characters in
>     position 18851-18854: ordinal not in range(128)
> 
>     > > on debian wheezy i386.  it didn't happen on amd64 and on both
>     architectures
>     > > under debian jessie (testing) and it seemed to happen while
>     testing with
>     > > python2.6
> 
>     > > On Mon, 16 Jun 2014, Robert Bradshaw wrote:
> 
>     > > > I just pushed another bugfix release for the 0.20.x line,
>     available on
>     > > > github, cython.org <http://cython.org>, or and pypi.
> 
>     > > > == Features added ==
> 
>     > > > * Some optimisations for set/frozenset instantiation.
>     > > > * Support for C++ unordered_set and unordered_map.
> 
>     > > > == Bugs fixed ==
> 
>     > > > * Access to attributes of optimised builtin methods (e.g.
>     > > > [].append.__name__) could fail to compile.
>     > > > * Memory leak when extension subtypes add a memory view as
>     attribute
>     > > > to those of the parent type without having Python object
>     attributes or
>     > > > a user provided dealloc method.
>     > > > * Compiler crash on readonly properties in "binding" mode.
>     > > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3.
>     > > > * Crash when subtyping freelist enabled Cython extension types
>     with
>     > > > Python classes that use __slots__.
>     > > > * Freelist usage is restricted to CPython to avoid problems
>     with other
>     > > > Python implementations.
>     > > > * Memory leak in memory views when copying overlapping,
>     contiguous slices.
>     > > > * Format checking when requesting non-contiguous buffers from
>     > > > cython.array objects was disabled in Py3.
>     > > > * C++ destructor calls in extension types could fail to
>     compile in clang.
>     > > > * Buffer format validation failed for sequences of strings in
>     structs.
>     > > > * Docstrings on extension type attributes in .pxd files were
>     rejected.
> 
>     > > > == Contributors ==
> 
>     > > > Andreas van Cranenburgh
>     > > > Ian Bell
>     > > > Lars Buitinck
>     > > > Martin Quarda
>     > > > Mikhail Korobov
>     > > > Robert Bradshaw
>     > > > Stefan Behnel
>     > > > _______________________________________________
>     > > > cython-devel mailing list
>     > > > cython-devel at python.org <mailto:cython-devel at python.org>
>     > > > https://mail.python.org/mailman/listinfo/cython-devel
>     --
>     Yaroslav O. Halchenko, Ph.D.
>     http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
>     Research Scientist,            Psychological and Brain Sciences Dept.
>     Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
>     Phone: +1 (603) 646-9834 <tel:%2B1%20%28603%29%20646-9834>          
>                 Fax: +1 (603) 646-1419 <tel:%2B1%20%28603%29%20646-1419>
>     WWW:   http://www.linkedin.com/in/yarik
>     _______________________________________________
>     cython-devel mailing list
>     cython-devel at python.org <mailto:cython-devel at python.org>
>     https://mail.python.org/mailman/listinfo/cython-devel
> 
> 
> 
> 
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
> 


From lists at onerussian.com  Tue Jul 22 18:48:01 2014
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 22 Jul 2014 12:48:01 -0400
Subject: [Cython] buffmt.__test__.wrongsize gets stuck after
	common_include_dir?
Message-ID: <20140722164801.GU8748@onerussian.com>

while trying to re-test Debian package build, in an interactive shell, I
get cython test stuck at:

...
Doctest: buffmt.__test__.wrongsize ... ok
runTest (__main__.EndToEndTest)
End-to-end basic_cythonize ... ok
runTest (__main__.EndToEndTest)
End-to-end basic_distutils ... ok
runTest (__main__.EndToEndTest)
End-to-end build_dir ... ok
runTest (__main__.EndToEndTest)
End-to-end common_include_dir ...

tests were executed using

runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir

any clues?  is it multiprocessing to blame again?

/bin/bash /tmp/hooks/C10shell
  /bin/bash
    /usr/bin/make -f debian/rules binary
      /usr/bin/perl -w /usr/bin/dh binary --with python2,python3 --buildsystem python_distutils
        /usr/bin/make -f debian/rules override_dh_auto_test
          /bin/sh -c set -e; for P in 2.7 3.4; do \          echo "PYTHON: $P"; \  export; \  PYTHONPATH=`/bin/ls -d /tmp/buildd/cython-0.20.2/build/lib.*-$P` \   /usr/bin/python$P runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir; \ done
            /usr/bin/python2.7 runtests.py --no-refnanny -v -v --exclude=parallel --work-dir=build/work-dir
              /bin/sh -c /usr/bin/python2.7 setup.py build_ext --inplace
                /usr/bin/python2.7 setup.py build_ext --inplace
                  /usr/bin/python2.7 setup.py build_ext --inplace
                  /usr/bin/python2.7 setup.py build_ext --inplace


-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

From lists at onerussian.com  Tue Jul 22 20:20:53 2014
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 22 Jul 2014 14:20:53 -0400
Subject: [Cython] Cython bugfix release
In-Reply-To: <53CD6131.9080700@googlemail.com>
References: <CADiQ+QAbqG+iXHp030EBpds4qZOKojM5Ypp7r8Ks-ZdmzZwSxw@mail.gmail.com>
 <20140618153740.GA8748@onerussian.com>
 <20140619152810.GC8748@onerussian.com>
 <20140720043939.GT8748@onerussian.com>
 <CADiQ+QDOF701kAxuiUyH03dF7LQkuMJj=011hes7t2suuDDFMw@mail.gmail.com>
 <53CD6131.9080700@googlemail.com>
Message-ID: <20140722182052.GV8748@onerussian.com>


On Mon, 21 Jul 2014, Julian Taylor wrote:

> I haven't tried it but its possibly related to the C locale the debian
> builders use. Try with LC_ALL=C

that is the one set

> @Yaroslav if this the the case, the workaround would be building with
> LC_ALL=C.UTF-8

good hint, although would not serve us as a workaround but rather possibly
reveals the actual problem if ran in interactive mode (if I pipe the output --
the same error)... 

the original error happens in the code which reacts to unsuccessful execution
of GdbDebuggerTestCaseand apparently has a problem with that unicode string
(although it was decoded from UTF-8 without errors).  To say the truth, unicode
handling philosophical understanding is not my strongest skill, BUT it seems to
spit out the actual error without failing if I explicitly encode that errmsg
back into UTF-8 and write that.  Alternative more generic implementation there
could be get a custom writer for stderr:

class TestAll(GdbDebuggerTestCase):

    def test_all(self):
        if not test_gdb():
            return

        out, err = self.p.communicate()
        err = err.decode('UTF-8')

        exit_status = self.p.returncode
        import codecs
        stderr = codecs.getwriter('utf8')(sys.stderr)

        if exit_status == 1:
            stderr.write(err)
        elif exit_status >= 2:
            border = u'*' * 30
            start  = u'%s   v INSIDE GDB v   %s' % (border, border)
            end    = u'%s   ^ INSIDE GDB ^   %s' % (border, border)
            errmsg = u'\n%s\n%s%s' % (start, err, end)
            
            stderr.write(errmsg)


With such code it spits out errmsg reliably:

python runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul  4 2014, 13:08:34)
[GCC 4.9.0]

Running tests against Cython 0.20.2
Backends: c,cpp

test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
******************************   v INSIDE GDB v   ******************************
warning: .cygdbinit: No such file or directory
EE...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception <type 'exceptions.KeyError'> (u'a',):
EFSystemError: ../Objects/moduleobject.c:50: bad argument to internal function
E...SystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception <class 'gdb.error'> The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
ESystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception <class 'gdb.error'> The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
EE.EEE.E.FFF
======================================================================
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
    return func(self, *args, **kwargs)
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 387, in test_cyset
    gdb.execute('cy set a = $cy_eval("{None: []}")')
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1860, in execute
    _execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.

======================================================================
ERROR: test_backtrace (Cython.Debugger.Tests.test_libcython_in_gdb.TestBacktrace)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
    return func(self, *args, **kwargs)
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 292, in test_backtrace
    result = gdb.execute('cy bt', to_string=True)
  File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1857, in execute
    _execute(command, from_tty)
error: Error occurred in Python command: 'FakeRepr' object has no attribute '__getitem__'

.... MORE ....


> On 21.07.2014 19:46, Robert Bradshaw wrote:
> > I wasn't able to reproduce this myself, which is why I haven't done
> > anything about it yet...


> > On Sat, Jul 19, 2014 at 9:39 PM, Yaroslav Halchenko
> > <lists at onerussian.com <mailto:lists at onerussian.com>> wrote:

> >     that was quite an underwhelming response,  now it is "official"
> >     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340
> >     and I haven't had yet a chance to recheck master... anyone has a clue
> >     before I start digging?

> >     On Thu, 19 Jun 2014, Yaroslav Halchenko wrote:

> >     > and the same issue in current(ish) master:

> >     > ======================================================================
> >     > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> >     > ----------------------------------------------------------------------
> >     > Traceback (most recent call last):
> >     >   File
> >     "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py",
> >     line 280, in test_all
> >     >     sys.stderr.write(errmsg)
> >     > UnicodeEncodeError: 'ascii' codec can't encode characters in
> >     position 21001-21004: ordinal not in range(128)

> >     > ----------------------------------------------------------------------
> >     > Ran 8348 tests in 2674.102s



> >     > On Wed, 18 Jun 2014, Yaroslav Halchenko wrote:

> >     > > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be
> >     available
> >     > > to Debian folks soon too

> >     > > while trying 0.20.1 across debian/ubuntus I ran into this failure


> >     ======================================================================
> >     > > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)

> >     ----------------------------------------------------------------------
> >     > > Traceback (most recent call last):
> >     > >   File
> >     "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py",
> >     line 281, in test_all
> >     > >     sys.stderr.write(errmsg)
> >     > > UnicodeEncodeError: 'ascii' codec can't encode characters in
> >     position 18851-18854: ordinal not in range(128)

> >     > > on debian wheezy i386.  it didn't happen on amd64 and on both
> >     architectures
> >     > > under debian jessie (testing) and it seemed to happen while
> >     testing with
> >     > > python2.6

> >     > > On Mon, 16 Jun 2014, Robert Bradshaw wrote:

> >     > > > I just pushed another bugfix release for the 0.20.x line,
> >     available on
> >     > > > github, cython.org <http://cython.org>, or and pypi.

> >     > > > == Features added ==

> >     > > > * Some optimisations for set/frozenset instantiation.
> >     > > > * Support for C++ unordered_set and unordered_map.

> >     > > > == Bugs fixed ==

> >     > > > * Access to attributes of optimised builtin methods (e.g.
> >     > > > [].append.__name__) could fail to compile.
> >     > > > * Memory leak when extension subtypes add a memory view as
> >     attribute
> >     > > > to those of the parent type without having Python object
> >     attributes or
> >     > > > a user provided dealloc method.
> >     > > > * Compiler crash on readonly properties in "binding" mode.
> >     > > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3.
> >     > > > * Crash when subtyping freelist enabled Cython extension types
> >     with
> >     > > > Python classes that use __slots__.
> >     > > > * Freelist usage is restricted to CPython to avoid problems
> >     with other
> >     > > > Python implementations.
> >     > > > * Memory leak in memory views when copying overlapping,
> >     contiguous slices.
> >     > > > * Format checking when requesting non-contiguous buffers from
> >     > > > cython.array objects was disabled in Py3.
> >     > > > * C++ destructor calls in extension types could fail to
> >     compile in clang.
> >     > > > * Buffer format validation failed for sequences of strings in
> >     structs.
> >     > > > * Docstrings on extension type attributes in .pxd files were
> >     rejected.

> >     > > > == Contributors ==

> >     > > > Andreas van Cranenburgh
> >     > > > Ian Bell
> >     > > > Lars Buitinck
> >     > > > Martin Quarda
> >     > > > Mikhail Korobov
> >     > > > Robert Bradshaw
> >     > > > Stefan Behnel
> >     > > > _______________________________________________
> >     > > > cython-devel mailing list
> >     > > > cython-devel at python.org <mailto:cython-devel at python.org>
> >     > > > https://mail.python.org/mailman/listinfo/cython-devel
> >     --
> >     Yaroslav O. Halchenko, Ph.D.
> >     http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> >     Research Scientist,            Psychological and Brain Sciences Dept.
> >     Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> >     Phone: +1 (603) 646-9834 <tel:%2B1%20%28603%29%20646-9834>          
> >                 Fax: +1 (603) 646-1419 <tel:%2B1%20%28603%29%20646-1419>
> >     WWW:   http://www.linkedin.com/in/yarik
> >     _______________________________________________
> >     cython-devel mailing list
> >     cython-devel at python.org <mailto:cython-devel at python.org>
> >     https://mail.python.org/mailman/listinfo/cython-devel




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


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


-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

From lists at onerussian.com  Tue Jul 22 20:59:39 2014
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 22 Jul 2014 14:59:39 -0400
Subject: [Cython] Cython bugfix release
In-Reply-To: <20140722182052.GV8748@onerussian.com>
References: <CADiQ+QAbqG+iXHp030EBpds4qZOKojM5Ypp7r8Ks-ZdmzZwSxw@mail.gmail.com>
 <20140618153740.GA8748@onerussian.com>
 <20140619152810.GC8748@onerussian.com>
 <20140720043939.GT8748@onerussian.com>
 <CADiQ+QDOF701kAxuiUyH03dF7LQkuMJj=011hes7t2suuDDFMw@mail.gmail.com>
 <53CD6131.9080700@googlemail.com>
 <20140722182052.GV8748@onerussian.com>
Message-ID: <20140722185939.GX8748@onerussian.com>

apparently relates back to
"Failing cygdb tests on master and 0.19.x"
https://groups.google.com/forum/#!topic/cython-users/SRKdbfftjMM

and https://github.com/cython/cython/pull/264

blind attempt to run with python-dbg build doesn't provide a relief (gdb is
7.7.1-2)

# PYTHONPATH=$PWD/build/lib.linux-x86_64-2.7-pydebug  python2.7-dbg runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul  4 2014, 13:12:00)
[GCC 4.9.0]

Running tests against Cython 0.20.2
Backends: c,cpp

test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
******************************   v INSIDE GDB v   ******************************
warning: .cygdbinit: No such file or directory
EF...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception <type 'exceptions.KeyError'> (u'a',):
EFTraceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined
F...Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined
FTraceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name 'some_random_var' is not defined
FE.EEE.E.FFF
======================================================================
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
    return func(self, *args, **kwargs)
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 387, in test_cyset
    gdb.execute('cy set a = $cy_eval("{None: []}")')
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/libpython.py", line 1860, in execute
    _execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.

======================================================================
ERROR: test_inner (Cython.Debugger.Tests.test_libcython_in_gdb.TestClosure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
    return func(self, *args, **kwargs)
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 420, in test_inner
    self.assertEqual(str(self.read_var('a')), "'an object'")
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
    return func(self, *args, **kwargs)
  File "/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 72, in read_var
    result = gdb.parse_and_eval('$cy_cvalue("%s")' % varname)
error: Error occurred in Python convenience function: (u'a',)

...



On Tue, 22 Jul 2014, Yaroslav Halchenko wrote:


> On Mon, 21 Jul 2014, Julian Taylor wrote:

> > I haven't tried it but its possibly related to the C locale the debian
> > builders use. Try with LC_ALL=C

> that is the one set

> > @Yaroslav if this the the case, the workaround would be building with
> > LC_ALL=C.UTF-8

> good hint, although would not serve us as a workaround but rather possibly
> reveals the actual problem if ran in interactive mode (if I pipe the output --
> the same error)... 

> the original error happens in the code which reacts to unsuccessful execution
> of GdbDebuggerTestCaseand apparently has a problem with that unicode string
> (although it was decoded from UTF-8 without errors).  To say the truth, unicode
> handling philosophical understanding is not my strongest skill, BUT it seems to
> spit out the actual error without failing if I explicitly encode that errmsg
> back into UTF-8 and write that.  Alternative more generic implementation there
> could be get a custom writer for stderr:

> class TestAll(GdbDebuggerTestCase):

>     def test_all(self):
>         if not test_gdb():
>             return

>         out, err = self.p.communicate()
>         err = err.decode('UTF-8')

>         exit_status = self.p.returncode
>         import codecs
>         stderr = codecs.getwriter('utf8')(sys.stderr)

>         if exit_status == 1:
>             stderr.write(err)
>         elif exit_status >= 2:
>             border = u'*' * 30
>             start  = u'%s   v INSIDE GDB v   %s' % (border, border)
>             end    = u'%s   ^ INSIDE GDB ^   %s' % (border, border)
>             errmsg = u'\n%s\n%s%s' % (start, err, end)

>             stderr.write(errmsg)


> With such code it spits out errmsg reliably:

> python runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir TestLibCython
> Python 2.7.8 (default, Jul  4 2014, 13:08:34)
> [GCC 4.9.0]

> Running tests against Cython 0.20.2
> Backends: c,cpp

> test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
> ******************************   v INSIDE GDB v   ******************************
> warning: .cygdbinit: No such file or directory
> EE...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
> Python Exception <type 'exceptions.KeyError'> (u'a',):
> EFSystemError: ../Objects/moduleobject.c:50: bad argument to internal function
> E...SystemError: ../Objects/moduleobject.c:50: bad argument to internal function
> Python Exception <class 'gdb.error'> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (PyModule_GetDict) will be abandoned.
> When the function is done executing, GDB will silently stop.:
> ESystemError: ../Objects/moduleobject.c:50: bad argument to internal function
> Python Exception <class 'gdb.error'> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (PyModule_GetDict) will be abandoned.
> When the function is done executing, GDB will silently stop.:
> EE.EEE.E.FFF
> ======================================================================
> ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
>     return func(self, *args, **kwargs)
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 387, in test_cyset
>     gdb.execute('cy set a = $cy_eval("{None: []}")')
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1860, in execute
>     _execute(command, from_tty)
> error: Selected frame does not correspond with a Cython function we know about.

> ======================================================================
> ERROR: test_backtrace (Cython.Debugger.Tests.test_libcython_in_gdb.TestBacktrace)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 38, in wrapper
>     return func(self, *args, **kwargs)
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py", line 292, in test_backtrace
>     result = gdb.execute('cy bt', to_string=True)
>   File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1857, in execute
>     _execute(command, from_tty)
> error: Error occurred in Python command: 'FakeRepr' object has no attribute '__getitem__'

> .... MORE ....


> > On 21.07.2014 19:46, Robert Bradshaw wrote:
> > > I wasn't able to reproduce this myself, which is why I haven't done
> > > anything about it yet...


> > > On Sat, Jul 19, 2014 at 9:39 PM, Yaroslav Halchenko
> > > <lists at onerussian.com <mailto:lists at onerussian.com>> wrote:

> > >     that was quite an underwhelming response,  now it is "official"
> > >     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755340
> > >     and I haven't had yet a chance to recheck master... anyone has a clue
> > >     before I start digging?

> > >     On Thu, 19 Jun 2014, Yaroslav Halchenko wrote:

> > >     > and the same issue in current(ish) master:

> > >     > ======================================================================
> > >     > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)
> > >     > ----------------------------------------------------------------------
> > >     > Traceback (most recent call last):
> > >     >   File
> > >     "/tmp/buildd/cython-0.20.2+git216-ga96882e/Cython/Debugger/Tests/TestLibCython.py",
> > >     line 280, in test_all
> > >     >     sys.stderr.write(errmsg)
> > >     > UnicodeEncodeError: 'ascii' codec can't encode characters in
> > >     position 21001-21004: ordinal not in range(128)

> > >     > ----------------------------------------------------------------------
> > >     > Ran 8348 tests in 2674.102s



> > >     > On Wed, 18 Jun 2014, Yaroslav Halchenko wrote:

> > >     > > FWIW -- 0.20.2 was just uploaded to Debian sid, thus should be
> > >     available
> > >     > > to Debian folks soon too

> > >     > > while trying 0.20.1 across debian/ubuntus I ran into this failure


> > >     ======================================================================
> > >     > > ERROR: test_all (Cython.Debugger.Tests.TestLibCython.TestAll)

> > >     ----------------------------------------------------------------------
> > >     > > Traceback (most recent call last):
> > >     > >   File
> > >     "/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/TestLibCython.py",
> > >     line 281, in test_all
> > >     > >     sys.stderr.write(errmsg)
> > >     > > UnicodeEncodeError: 'ascii' codec can't encode characters in
> > >     position 18851-18854: ordinal not in range(128)

> > >     > > on debian wheezy i386.  it didn't happen on amd64 and on both
> > >     architectures
> > >     > > under debian jessie (testing) and it seemed to happen while
> > >     testing with
> > >     > > python2.6

> > >     > > On Mon, 16 Jun 2014, Robert Bradshaw wrote:

> > >     > > > I just pushed another bugfix release for the 0.20.x line,
> > >     available on
> > >     > > > github, cython.org <http://cython.org>, or and pypi.

> > >     > > > == Features added ==

> > >     > > > * Some optimisations for set/frozenset instantiation.
> > >     > > > * Support for C++ unordered_set and unordered_map.

> > >     > > > == Bugs fixed ==

> > >     > > > * Access to attributes of optimised builtin methods (e.g.
> > >     > > > [].append.__name__) could fail to compile.
> > >     > > > * Memory leak when extension subtypes add a memory view as
> > >     attribute
> > >     > > > to those of the parent type without having Python object
> > >     attributes or
> > >     > > > a user provided dealloc method.
> > >     > > > * Compiler crash on readonly properties in "binding" mode.
> > >     > > > * Auto-encoding with c_string_encoding=ascii failed in Py3.3.
> > >     > > > * Crash when subtyping freelist enabled Cython extension types
> > >     with
> > >     > > > Python classes that use __slots__.
> > >     > > > * Freelist usage is restricted to CPython to avoid problems
> > >     with other
> > >     > > > Python implementations.
> > >     > > > * Memory leak in memory views when copying overlapping,
> > >     contiguous slices.
> > >     > > > * Format checking when requesting non-contiguous buffers from
> > >     > > > cython.array objects was disabled in Py3.
> > >     > > > * C++ destructor calls in extension types could fail to
> > >     compile in clang.
> > >     > > > * Buffer format validation failed for sequences of strings in
> > >     structs.
> > >     > > > * Docstrings on extension type attributes in .pxd files were
> > >     rejected.

> > >     > > > == Contributors ==

> > >     > > > Andreas van Cranenburgh
> > >     > > > Ian Bell
> > >     > > > Lars Buitinck
> > >     > > > Martin Quarda
> > >     > > > Mikhail Korobov
> > >     > > > Robert Bradshaw
> > >     > > > Stefan Behnel
> > >     > > > _______________________________________________
> > >     > > > cython-devel mailing list
> > >     > > > cython-devel at python.org <mailto:cython-devel at python.org>
> > >     > > > https://mail.python.org/mailman/listinfo/cython-devel
> > >     --
> > >     Yaroslav O. Halchenko, Ph.D.
> > >     http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> > >     Research Scientist,            Psychological and Brain Sciences Dept.
> > >     Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> > >     Phone: +1 (603) 646-9834 <tel:%2B1%20%28603%29%20646-9834>          
> > >                 Fax: +1 (603) 646-1419 <tel:%2B1%20%28603%29%20646-1419>
> > >     WWW:   http://www.linkedin.com/in/yarik
> > >     _______________________________________________
> > >     cython-devel mailing list
> > >     cython-devel at python.org <mailto:cython-devel at python.org>
> > >     https://mail.python.org/mailman/listinfo/cython-devel




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


> > _______________________________________________
> > cython-devel mailing list
> > cython-devel at python.org
> > https://mail.python.org/mailman/listinfo/cython-devel
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Research Scientist,            Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

From robertwb at gmail.com  Wed Jul 23 06:57:32 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Tue, 22 Jul 2014 21:57:32 -0700
Subject: [Cython] License information on each individual files
In-Reply-To: <53CB71AD.9040805@behnel.de>
References: <CAEpg0+nHfWkz8y6WKRP6Nb-goDX12pMPrUMCGEc4gWakxpG9cg@mail.gmail.com>
 <1225386003427410064.513079sturla.molden-gmail.com@news.gmane.org>
 <CAPJVwB=HJr9SZd88R=mbqFfG8LchsvLoBeqcHb0m6u1_pSjh5g@mail.gmail.com>
 <CADiQ+QByRgsnDBimKp6uPxQR6f-g-VTe5bY2pQz=tZxJUqwNdg@mail.gmail.com>
 <CAPJVwBnj6nr1q8nvLqKEd_8VxAbWPgETpbvAqjxGiNX0RNeAfQ@mail.gmail.com>
 <CADiQ+QCqLKa_TZ60bQtuAnSTaMHnUHdcRZZaKg9mw6xjsaepUA@mail.gmail.com>
 <730946162427415434.925262sturla.molden-gmail.com@news.gmane.org>
 <53CA12A8.5020606@behnel.de>
 <CAPJVwB=na8H8250r2eWevPXt5HRF4ODwTHhiUZtv4XsFkcHaQQ@mail.gmail.com>
 <53CB71AD.9040805@behnel.de>
Message-ID: <CADiQ+QAea5YYdTOTYUtYbV97=wnRz8i4UpcTqh=DekF0sL1gFQ@mail.gmail.com>

On Sun, Jul 20, 2014 at 12:37 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>
> Nathaniel Smith, 19.07.2014 19:42:
> > On Sat, Jul 19, 2014 at 7:39 AM, Stefan Behnel wrote:
> >> Sturla Molden, 19.07.2014 00:36:
> >>> Robert Bradshaw wrote:
> >>>> It's not just the initial patch; I'm primarily worried about the
> >>>> maintenance burden
> >>>
> >>> And also, will it break utility code and binary blobs? It might not even be
> >>> safe to put it in every file.
> >>>
> >>> And when put in files with utility C code, will it be included in the
> >>> generated .c file and taint this file with a notification about Cython's
> >>> Apache license?
> >>
> >> Well, on the technical side, stuff at the beginning of a utility code file
> >> should just be ignored, up to the first header line (starting with a
> >> sequence of at least 5 comment characters). Some of them already contain
> >> leading comments anyway.
> >>
> >> On the legal side, the licensing state of the generated code does not
> >> change by copying the license description from the global license file into
> >> each code file, because the global license already applies to the complete
> >> code base anyway (unless stated otherwise).
> >>
> >> However, what *is* the licensing state of the generated code? Strictly
> >> speaking, the code generated by Cython, all parts of which are embedded in
> >> Cython's own source code, could be considered a "derivative work" by some.
> >
> > I suspect that "some" includes most lawyers and judges ;-). There's
> > tons of copyrightable code copied into Cython output.
>
> The bulk of what gets "copied" are really just tiny character sequences
> each of which would be impossible to protect legally. And they even get
> substantially modified before being written out. But there's probably still
> plenty of room for lawyers to sell days of work here, and the utility code
> files form a major piece of work by themselves that gets copied into the
> generated code in substantial (i.e. protectable) chunks.

Agreed, but if someone wrote a new Python-to-C compiler and grabbed
all our UtilityCodes to do so that would IMHO constitute a derivative
work.

> >> From my side, that statement definitely still applies. I really don't want
> >> to have anything to say on what users do with the code generated from their
> >> own source code. I do not even consider the generated code a "derivative
> >> work" myself, but IANAL...

Yep. That's been the position every time the topic has come up, and
has been on our wiki for quite a while. I've clarified it here:

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

From robertwb at gmail.com  Wed Jul 23 08:42:24 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Tue, 22 Jul 2014 23:42:24 -0700
Subject: [Cython] Compiler crash: forward declaration of cdef class with
 "public" attributes
In-Reply-To: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>
References: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>
Message-ID: <CADiQ+QA3P_R=Sf4cKcjG9BCjYfihPTdBhuVfxUrZYj2Tift2+g@mail.gmail.com>

On Tue, Jul 8, 2014 at 4:34 PM, Alok Singhal <gandalf013 at gmail.com> wrote:
> Hi,
>
> I am getting a compiler crash with the following code:
>
> $ cat foo.pxd
> cdef class Foo:
>     cdef public object x
> $ cat foo.pyx
> cdef class Foo
>
> cdef class Foo:
>     pass
> $ ./cython.py  foo.pyx
>
> Error compiling Cython file:
> ------------------------------------------------------------
> ...
> cdef class Foo
>     ^
> ------------------------------------------------------------
>
> foo.pyx:1:5: Compiler crash in AnalyseDeclarationsTransform
>
> ModuleNode.body = StatListNode(foo.pyx:1:0)
> StatListNode.stats[0] = CClassDefNode(foo.pyx:1:5,
>     as_name = u'Foo',
>     class_name = u'Foo',
>     module_name = '',
>     visibility = 'private')
>
> Compiler crash traceback from this point on:
>   File "/Users/alok/Downloads/repos/cython.git/Cython/Compiler/Visitor.py",
> line 173, in _visit
>     return handler_method(obj)
>   File
> "/Users/alok/Downloads/repos/cython.git/Cython/Compiler/ParseTreeTransforms.py",
> line 1478, in visit_CClassDefNode
>     node.body.stats += stats
> AttributeError: 'NoneType' object has no attribute 'stats'
>
> The problem seems to be due to having a .pxd file with the attributes of the
> cdef class in it.  Since the attributes are declared "public", Cython is
> trying to generate property code for "Foo.x".  But it's trying to do that at
> the point of forward declaration in the .pyx file, instead of the definition
> of the class.
>
> An easy fix seems to be to change
> AnalyseDeclarationsTransform.visit_CClassDefNode in ParseTreeTransforms.py
> to check for node.body not being none.  I.e., the following patch seems to
> work:
>
> diff --git a/Cython/Compiler/ParseTreeTransforms.py
> b/Cython/Compiler/ParseTreeTransforms.py
> index f8c2efa..7811d56 100644
> --- a/Cython/Compiler/ParseTreeTransforms.py
> +++ b/Cython/Compiler/ParseTreeTransforms.py
> @@ -1466,7 +1466,7 @@ if VALUE is not None:
>
>      def visit_CClassDefNode(self, node):
>          node = self.visit_ClassDefNode(node)
> -        if node.scope and node.scope.implemented:
> +        if node.body and node.scope and node.scope.implemented:
>              stats = []
>              for entry in node.scope.var_entries:
>                  if entry.needs_property:
>
> Thanks,
> Alok

Thanks. https://github.com/cython/cython/commit/967c8e11da94ddae1ea7f1524f6beef2e030c4d9

FWIW, forward declarations should not generally be needed, and
certainly not needed if the class is already declared in a pxd file.

From gandalf013 at gmail.com  Wed Jul 23 09:29:50 2014
From: gandalf013 at gmail.com (Alok Singhal)
Date: Wed, 23 Jul 2014 00:29:50 -0700
Subject: [Cython] Compiler crash: forward declaration of cdef class with
 "public" attributes
In-Reply-To: <CADiQ+QA3P_R=Sf4cKcjG9BCjYfihPTdBhuVfxUrZYj2Tift2+g@mail.gmail.com>
References: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>
 <CADiQ+QA3P_R=Sf4cKcjG9BCjYfihPTdBhuVfxUrZYj2Tift2+g@mail.gmail.com>
Message-ID: <CAPh9ZXr9kOgLFd=p0XQtrGgkvCV8E+hV5UZ6qBcixdudGNpK4A@mail.gmail.com>

On Tue, Jul 22, 2014 at 11:42 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Tue, Jul 8, 2014 at 4:34 PM, Alok Singhal <gandalf013 at gmail.com> wrote:
>
> Thanks. https://github.com/cython/cython/commit/967c8e11da94ddae1ea7f1524f6beef2e030c4d9

Thanks for the fix!

> FWIW, forward declarations should not generally be needed, and
> certainly not needed if the class is already declared in a pxd file.

I encountered this problem because we have a tool that generates .pxd
files automatically from a .pyx file, and that tool ends up generating
code like this in certain cases.

Also, if forward declarations are not recommended, what is the best
way to declare two cdef classes that need to know about each other?
(Short of "don't do that!" :-) ).

Thanks,
Alok

From robertwb at gmail.com  Wed Jul 23 17:28:41 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Wed, 23 Jul 2014 08:28:41 -0700
Subject: [Cython] Compiler crash: forward declaration of cdef class with
 "public" attributes
In-Reply-To: <CAPh9ZXr9kOgLFd=p0XQtrGgkvCV8E+hV5UZ6qBcixdudGNpK4A@mail.gmail.com>
References: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>
 <CADiQ+QA3P_R=Sf4cKcjG9BCjYfihPTdBhuVfxUrZYj2Tift2+g@mail.gmail.com>
 <CAPh9ZXr9kOgLFd=p0XQtrGgkvCV8E+hV5UZ6qBcixdudGNpK4A@mail.gmail.com>
Message-ID: <CADiQ+QCwZKdN=g+cQ0BKOGEVaBnhECVV=-kNVP77RptGHP6=MQ@mail.gmail.com>

On Wed, Jul 23, 2014 at 12:29 AM, Alok Singhal <gandalf013 at gmail.com> wrote:
> On Tue, Jul 22, 2014 at 11:42 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>> On Tue, Jul 8, 2014 at 4:34 PM, Alok Singhal <gandalf013 at gmail.com> wrote:
>>
>> Thanks. https://github.com/cython/cython/commit/967c8e11da94ddae1ea7f1524f6beef2e030c4d9
>
> Thanks for the fix!
>
>> FWIW, forward declarations should not generally be needed, and
>> certainly not needed if the class is already declared in a pxd file.
>
> I encountered this problem because we have a tool that generates .pxd
> files automatically from a .pyx file, and that tool ends up generating
> code like this in certain cases.
>
> Also, if forward declarations are not recommended, what is the best
> way to declare two cdef classes that need to know about each other?
> (Short of "don't do that!" :-) ).

Just do it without the forward declarations.

- Robert

From gandalf013 at gmail.com  Wed Jul 23 18:34:37 2014
From: gandalf013 at gmail.com (Alok Singhal)
Date: Wed, 23 Jul 2014 09:34:37 -0700
Subject: [Cython] Compiler crash: forward declaration of cdef class with
 "public" attributes
In-Reply-To: <CADiQ+QCwZKdN=g+cQ0BKOGEVaBnhECVV=-kNVP77RptGHP6=MQ@mail.gmail.com>
References: <CAPh9ZXpX6b95ESamz1JNH_=SWsy+UEgvF1DXe93NjwmNbdVG4w@mail.gmail.com>
 <CADiQ+QA3P_R=Sf4cKcjG9BCjYfihPTdBhuVfxUrZYj2Tift2+g@mail.gmail.com>
 <CAPh9ZXr9kOgLFd=p0XQtrGgkvCV8E+hV5UZ6qBcixdudGNpK4A@mail.gmail.com>
 <CADiQ+QCwZKdN=g+cQ0BKOGEVaBnhECVV=-kNVP77RptGHP6=MQ@mail.gmail.com>
Message-ID: <CAPh9ZXrmJa5rCZGN1zCs86oaM+=ruCiQ0-R_vbruZMbVgx683A@mail.gmail.com>

On Wed, Jul 23, 2014 at 8:28 AM, Robert Bradshaw <robertwb at gmail.com> wrote:
>> Also, if forward declarations are not recommended, what is the best
>> way to declare two cdef classes that need to know about each other?
>> (Short of "don't do that!" :-) ).
>
> Just do it without the forward declarations.

Thanks!  I didn't realize that I didn't need forward declarations.

-Alok

From robertwb at gmail.com  Thu Jul 24 21:07:38 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 24 Jul 2014 12:07:38 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
Message-ID: <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>

On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
> On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>>>
>>>
>>> Yes, this'd be nice to have. One difficulty with arrays is that they
>>> can't be returned by value, and so the ordinary from_py_function
>>> mechanism (which gets called recursively) would need to be adapted.
>>> (Allowing to_py_function to be optinally be called by reference
>>> instead of by value could be nice as well from a performance
>>> standpoint.)
>>
>>
>> OK, thanks for the pointers.  I'll put some time on this over the weekend.
>> Should I just make a PR when things are ready to review, or should I put up
>> an issue first?
>
> I think this thread is sufficient; looking forward to a pull request.

Don't know if you had time to look at this yet, but another possible
hack would be to use the fact that struct { int x[N]; } is bit
compatible with int[N] and can be passed/assigned by value. E.g.

struct wrapped_array {
    int x[3];
};

int main(int argc, char** argv) {
    int src[3];
    int dest[3];
    *((struct wrapped_array *) &dest) = *((struct wrapped_array *) &src);
}

OTOH, it might make sense to simply add array members as a special
case in struct conversion.

- Robert

From kwmsmith at gmail.com  Fri Jul 25 04:13:58 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Thu, 24 Jul 2014 21:13:58 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
Message-ID: <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>

On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com> wrote:

> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
> >>>
> >>>
> >>> Yes, this'd be nice to have. One difficulty with arrays is that they
> >>> can't be returned by value, and so the ordinary from_py_function
> >>> mechanism (which gets called recursively) would need to be adapted.
> >>> (Allowing to_py_function to be optinally be called by reference
> >>> instead of by value could be nice as well from a performance
> >>> standpoint.)
> >>
> >>
> >> OK, thanks for the pointers.  I'll put some time on this over the
> weekend.
> >> Should I just make a PR when things are ready to review, or should I
> put up
> >> an issue first?
> >
> > I think this thread is sufficient; looking forward to a pull request.
>
> Don't know if you had time to look at this yet,


Yes, I've put in some time.  Initial focus is getting

    cdef int a[10] = obj

working, and then using that for structs.

Took a little while to re-orient myself with the codebase.

I'm working on getting the `to_py_function` and `from_py_function`
infrastructure to take arguments by reference; right now I'm getting
something hacked into place, and I'd appreciate your review to point out
the right way (or at least a better way) to do it.

Will likely have a PR for you by this weekend.


> but another possible
> hack would be to use the fact that struct { int x[N]; } is bit
> compatible with int[N] and can be passed/assigned by value. E.g.
>

Yes, this is a good point, although if I can get the pass-by-reference
working for fixed-size arrays, ideally we can do the same for structs with
array members.


>
> struct wrapped_array {
>     int x[3];
> };
>
> int main(int argc, char** argv) {
>     int src[3];
>     int dest[3];
>     *((struct wrapped_array *) &dest) = *((struct wrapped_array *) &src);
> }
>
> OTOH, it might make sense to simply add array members as a special
> case in struct conversion.
>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140724/6d94379a/attachment.html>

From robertwb at gmail.com  Fri Jul 25 06:16:37 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 24 Jul 2014 21:16:37 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
Message-ID: <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>

On Thu, Jul 24, 2014 at 7:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>
> On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com> wrote:
>>
>> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com>
>> wrote:
>> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> Yes, this'd be nice to have. One difficulty with arrays is that they
>> >>> can't be returned by value, and so the ordinary from_py_function
>> >>> mechanism (which gets called recursively) would need to be adapted.
>> >>> (Allowing to_py_function to be optinally be called by reference
>> >>> instead of by value could be nice as well from a performance
>> >>> standpoint.)
>> >>
>> >>
>> >> OK, thanks for the pointers.  I'll put some time on this over the
>> >> weekend.
>> >> Should I just make a PR when things are ready to review, or should I
>> >> put up
>> >> an issue first?
>> >
>> > I think this thread is sufficient; looking forward to a pull request.
>>
>> Don't know if you had time to look at this yet,
>
>
> Yes, I've put in some time.  Initial focus is getting
>
>     cdef int a[10] = obj
>
> working, and then using that for structs.

Sounds good.

> Took a little while to re-orient myself with the codebase.
>
> I'm working on getting the `to_py_function` and `from_py_function`
> infrastructure to take arguments by reference; right now I'm getting
> something hacked into place, and I'd appreciate your review to point out the
> right way (or at least a better way) to do it.

from_py_function always takes its argument (a PyObject*) by reference.
It's used as an rvalue, so might not make sense for arrays.

> Will likely have a PR for you by this weekend.

Cool.

>> but another possible
>> hack would be to use the fact that struct { int x[N]; } is bit
>> compatible with int[N] and can be passed/assigned by value. E.g.
>
>
> Yes, this is a good point, although if I can get the pass-by-reference
> working for fixed-size arrays, ideally we can do the same for structs with
> array members.

Agreed.

- Robert

From kwmsmith at gmail.com  Fri Jul 25 17:24:48 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Fri, 25 Jul 2014 10:24:48 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>
Message-ID: <CALpTaNbjGta82ShrhG=7VD6s=nAvo1+bQGi72sHFRS2AdsW0CA@mail.gmail.com>

On Thu, Jul 24, 2014 at 11:16 PM, Robert Bradshaw <robertwb at gmail.com>
wrote:

> On Thu, Jul 24, 2014 at 7:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
> >
> > On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
> >>
> >> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com>
> >> wrote:
> >> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com>
> wrote:
> >> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <robertwb at gmail.com
> >
> >> >> wrote:
> >> >>>
> >> >>>
> >> >>> Yes, this'd be nice to have. One difficulty with arrays is that they
> >> >>> can't be returned by value, and so the ordinary from_py_function
> >> >>> mechanism (which gets called recursively) would need to be adapted.
> >> >>> (Allowing to_py_function to be optinally be called by reference
> >> >>> instead of by value could be nice as well from a performance
> >> >>> standpoint.)
> >> >>
> >> >>
> >> >> OK, thanks for the pointers.  I'll put some time on this over the
> >> >> weekend.
> >> >> Should I just make a PR when things are ready to review, or should I
> >> >> put up
> >> >> an issue first?
> >> >
> >> > I think this thread is sufficient; looking forward to a pull request.
> >>
> >> Don't know if you had time to look at this yet,
> >
> >
> > Yes, I've put in some time.  Initial focus is getting
> >
> >     cdef int a[10] = obj
> >
> > working, and then using that for structs.
>
> Sounds good.
>
> > Took a little while to re-orient myself with the codebase.
> >
> > I'm working on getting the `to_py_function` and `from_py_function`
> > infrastructure to take arguments by reference; right now I'm getting
> > something hacked into place, and I'd appreciate your review to point out
> the
> > right way (or at least a better way) to do it.
>
> from_py_function always takes its argument (a PyObject*) by reference.
> It's used as an rvalue, so might not make sense for arrays.
>

My bad, I worded my response poorly -- what I mean is that currently the
generated code is something like:

    __pyx_v_t1 = xxx_from_py_function_xxx(temp_py_obj);

    ___pyx_v_a = __pyx_v_t1;

where __pyx_v_a and __pyx_v_t1 are declared as fixed-size C arrays.

This won't work, for reasons pointed out.

So I'm trying to generate instead:

    err_code = xxx_from_py_function_xxx(temp_py_obj, &__pyx_v_a[0], 10);
 if (err_code == -1) { ... }

Where the 10 is the array length.  The function would initialize the array
internally.  The python object is passed by reference as before, and the
array is also passed by reference.  The array is assigned to just once,
minimizing copying.  We can return a status code to propagate errors, etc.
 This seems like the cleanest code to me.  Thoughts?

That's what I mean about "taking arguments by reference".


> > Will likely have a PR for you by this weekend.
>
> Cool.
>
> >> but another possible
> >> hack would be to use the fact that struct { int x[N]; } is bit
> >> compatible with int[N] and can be passed/assigned by value. E.g.
> >
> >
> > Yes, this is a good point, although if I can get the pass-by-reference
> > working for fixed-size arrays, ideally we can do the same for structs
> with
> > array members.
>
> Agreed.
>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140725/664fd3e4/attachment.html>

From robertwb at math.washington.edu  Fri Jul 25 20:16:27 2014
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Fri, 25 Jul 2014 11:16:27 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNbjGta82ShrhG=7VD6s=nAvo1+bQGi72sHFRS2AdsW0CA@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>
 <CALpTaNbjGta82ShrhG=7VD6s=nAvo1+bQGi72sHFRS2AdsW0CA@mail.gmail.com>
Message-ID: <CADiQ+QC2PhvzTn1zpf-W_==M7g9yc9MCytKmwd=gHf=P1Y0z6g@mail.gmail.com>

On Fri, Jul 25, 2014 at 8:24 AM, Kurt Smith <kwmsmith at gmail.com> wrote:

>
> On Thu, Jul 24, 2014 at 11:16 PM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
>
>> On Thu, Jul 24, 2014 at 7:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>> >
>> > On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com>
>> wrote:
>> >>
>> >> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com>
>> >> wrote:
>> >> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com>
>> wrote:
>> >> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <
>> robertwb at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>>
>> >> >>> Yes, this'd be nice to have. One difficulty with arrays is that
>> they
>> >> >>> can't be returned by value, and so the ordinary from_py_function
>> >> >>> mechanism (which gets called recursively) would need to be adapted.
>> >> >>> (Allowing to_py_function to be optinally be called by reference
>> >> >>> instead of by value could be nice as well from a performance
>> >> >>> standpoint.)
>> >> >>
>> >> >>
>> >> >> OK, thanks for the pointers.  I'll put some time on this over the
>> >> >> weekend.
>> >> >> Should I just make a PR when things are ready to review, or should I
>> >> >> put up
>> >> >> an issue first?
>> >> >
>> >> > I think this thread is sufficient; looking forward to a pull request.
>> >>
>> >> Don't know if you had time to look at this yet,
>> >
>> >
>> > Yes, I've put in some time.  Initial focus is getting
>> >
>> >     cdef int a[10] = obj
>> >
>> > working, and then using that for structs.
>>
>> Sounds good.
>>
>> > Took a little while to re-orient myself with the codebase.
>> >
>> > I'm working on getting the `to_py_function` and `from_py_function`
>> > infrastructure to take arguments by reference; right now I'm getting
>> > something hacked into place, and I'd appreciate your review to point
>> out the
>> > right way (or at least a better way) to do it.
>>
>> from_py_function always takes its argument (a PyObject*) by reference.
>> It's used as an rvalue, so might not make sense for arrays.
>>
>
> My bad, I worded my response poorly -- what I mean is that currently the
> generated code is something like:
>
>     __pyx_v_t1 = xxx_from_py_function_xxx(temp_py_obj);
>
>     ___pyx_v_a = __pyx_v_t1;
>
> where __pyx_v_a and __pyx_v_t1 are declared as fixed-size C arrays.
>
> This won't work, for reasons pointed out.
>
> So I'm trying to generate instead:
>
>     err_code = xxx_from_py_function_xxx(temp_py_obj, &__pyx_v_a[0], 10);
>  if (err_code == -1) { ... }
>

FWIW think you can just write &__pyx_v_a


> Where the 10 is the array length.  The function would initialize the array
> internally.  The python object is passed by reference as before, and the
> array is also passed by reference.  The array is assigned to just once,
> minimizing copying.  We can return a status code to propagate errors, etc.
>  This seems like the cleanest code to me.  Thoughts?
>

Yes, that makes sense.

One of my concerns was whether xxx_from_py_function_xxx was always assigned
to an lvalue, enabling this transformation, but I think with error checking
it's always assigned to a temporary, so we're OK here.

Are you thinking of transforming all xxx_from_py_function_xxx to be of this
form? It could make sense for structs, and make for cleaner error checking,
but would there be more overhead for simple types like converting to a long
(which are currently macros)? If the length is an argument, would one have
to check for whether to pass this at every use of the from_py_function?
(Maybe that could be encapsulated away into a method on the type, but I
think it's used in quite a few places.)

All that being said, it'll be really nice to get this working.

- Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140725/c44fe20b/attachment.html>

From kwmsmith at gmail.com  Fri Jul 25 22:30:17 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Fri, 25 Jul 2014 15:30:17 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QC2PhvzTn1zpf-W_==M7g9yc9MCytKmwd=gHf=P1Y0z6g@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>
 <CALpTaNbjGta82ShrhG=7VD6s=nAvo1+bQGi72sHFRS2AdsW0CA@mail.gmail.com>
 <CADiQ+QC2PhvzTn1zpf-W_==M7g9yc9MCytKmwd=gHf=P1Y0z6g@mail.gmail.com>
Message-ID: <CALpTaNY6GcN28hNOTOeUKjxUubfgZXmhmNFp-+SO07jECEqCRA@mail.gmail.com>

On Fri, Jul 25, 2014 at 1:16 PM, Robert Bradshaw <
robertwb at math.washington.edu> wrote:

> On Fri, Jul 25, 2014 at 8:24 AM, Kurt Smith <kwmsmith at gmail.com> wrote:
>
>>
>> On Thu, Jul 24, 2014 at 11:16 PM, Robert Bradshaw <robertwb at gmail.com>
>> wrote:
>>
>>> On Thu, Jul 24, 2014 at 7:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>>> >
>>> > On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com>
>>> wrote:
>>> >>
>>> >> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw <robertwb at gmail.com
>>> >
>>> >> wrote:
>>> >> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com>
>>> wrote:
>>> >> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw <
>>> robertwb at gmail.com>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>> Yes, this'd be nice to have. One difficulty with arrays is that
>>> they
>>> >> >>> can't be returned by value, and so the ordinary from_py_function
>>> >> >>> mechanism (which gets called recursively) would need to be
>>> adapted.
>>> >> >>> (Allowing to_py_function to be optinally be called by reference
>>> >> >>> instead of by value could be nice as well from a performance
>>> >> >>> standpoint.)
>>> >> >>
>>> >> >>
>>> >> >> OK, thanks for the pointers.  I'll put some time on this over the
>>> >> >> weekend.
>>> >> >> Should I just make a PR when things are ready to review, or should
>>> I
>>> >> >> put up
>>> >> >> an issue first?
>>> >> >
>>> >> > I think this thread is sufficient; looking forward to a pull
>>> request.
>>> >>
>>> >> Don't know if you had time to look at this yet,
>>> >
>>> >
>>> > Yes, I've put in some time.  Initial focus is getting
>>> >
>>> >     cdef int a[10] = obj
>>> >
>>> > working, and then using that for structs.
>>>
>>> Sounds good.
>>>
>>> > Took a little while to re-orient myself with the codebase.
>>> >
>>> > I'm working on getting the `to_py_function` and `from_py_function`
>>> > infrastructure to take arguments by reference; right now I'm getting
>>> > something hacked into place, and I'd appreciate your review to point
>>> out the
>>> > right way (or at least a better way) to do it.
>>>
>>> from_py_function always takes its argument (a PyObject*) by reference.
>>> It's used as an rvalue, so might not make sense for arrays.
>>>
>>
>> My bad, I worded my response poorly -- what I mean is that currently the
>> generated code is something like:
>>
>>     __pyx_v_t1 = xxx_from_py_function_xxx(temp_py_obj);
>>
>>     ___pyx_v_a = __pyx_v_t1;
>>
>> where __pyx_v_a and __pyx_v_t1 are declared as fixed-size C arrays.
>>
>> This won't work, for reasons pointed out.
>>
>> So I'm trying to generate instead:
>>
>>     err_code = xxx_from_py_function_xxx(temp_py_obj, &__pyx_v_a[0], 10);
>>  if (err_code == -1) { ... }
>>
>
> FWIW think you can just write &__pyx_v_a
>

Yes, thanks, this form will also generalize to multidimensional fixed-sized
arrays.  For that matter, we can just pass in __pyx_v_a, which is
equivalent to either &__pyx_v_a or &__pyx_v_a[0] (K&R 5.3).


>
>
>> Where the 10 is the array length.  The function would initialize the
>> array internally.  The python object is passed by reference as before, and
>> the array is also passed by reference.  The array is assigned to just once,
>> minimizing copying.  We can return a status code to propagate errors, etc.
>>  This seems like the cleanest code to me.  Thoughts?
>>
>
> Yes, that makes sense.
>
> One of my concerns was whether xxx_from_py_function_xxx was always
> assigned to an lvalue, enabling this transformation, but I think with error
> checking it's always assigned to a temporary, so we're OK here.
>
>
Sorry, I didn't quite follow that.  The lhs is an lvalue at the C level
already, right?  And we'd want to use the array variable directly in the
xxx_from_py_function_xxx call, not a temporary, since the `__pyx_v_a =
__pyx_v_t1` temp assignment won't work.  What am I missing here?


Are you thinking of transforming all xxx_from_py_function_xxx to be of this
> form?
>

No, I was thinking this would kick in for just fixed-size arrays, structs,
and perhaps others as makes sense.  Everything else would remain as-is.


> It could make sense for structs, and make for cleaner error checking, but
> would there be more overhead for simple types like converting to a long
> (which are currently macros)?
>

Agreed.  Simple types should remain as-is.


> If the length is an argument, would one have to check for whether to pass
> this at every use of the from_py_function?
>

No, my thinking is that this transformation (and passing in the array size)
would only apply for fixed-size arrays.


> (Maybe that could be encapsulated away into a method on the type, but I
> think it's used in quite a few places.)
>

> All that being said, it'll be really nice to get this working.
>
> - Robert
>
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140725/a486fec9/attachment-0001.html>

From robertwb at gmail.com  Fri Jul 25 22:44:49 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Fri, 25 Jul 2014 13:44:49 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNY6GcN28hNOTOeUKjxUubfgZXmhmNFp-+SO07jECEqCRA@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CADiQ+QD9Bb3wbm9k+bPQ+vwNbr+8Kuj6BYHd_nytkJH7qTKyjw@mail.gmail.com>
 <CALpTaNbjGta82ShrhG=7VD6s=nAvo1+bQGi72sHFRS2AdsW0CA@mail.gmail.com>
 <CADiQ+QC2PhvzTn1zpf-W_==M7g9yc9MCytKmwd=gHf=P1Y0z6g@mail.gmail.com>
 <CALpTaNY6GcN28hNOTOeUKjxUubfgZXmhmNFp-+SO07jECEqCRA@mail.gmail.com>
Message-ID: <CADiQ+QB8oKq-_1z11FrCKszECuNkKDcPsgUH30+QLK5Att9sLQ@mail.gmail.com>

On Fri, Jul 25, 2014 at 1:30 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>
>
> On Fri, Jul 25, 2014 at 1:16 PM, Robert Bradshaw
> <robertwb at math.washington.edu> wrote:
>>
>> On Fri, Jul 25, 2014 at 8:24 AM, Kurt Smith <kwmsmith at gmail.com> wrote:
>>>
>>>
>>> On Thu, Jul 24, 2014 at 11:16 PM, Robert Bradshaw <robertwb at gmail.com>
>>> wrote:
>>>>
>>>> On Thu, Jul 24, 2014 at 7:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>>>> >
>>>> > On Thu, Jul 24, 2014 at 2:07 PM, Robert Bradshaw <robertwb at gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> On Fri, Jul 18, 2014 at 12:44 PM, Robert Bradshaw
>>>> >> <robertwb at gmail.com>
>>>> >> wrote:
>>>> >> > On Fri, Jul 18, 2014 at 12:08 PM, Kurt Smith <kwmsmith at gmail.com>
>>>> >> > wrote:
>>>> >> >> On Wed, Jul 16, 2014 at 1:02 PM, Robert Bradshaw
>>>> >> >> <robertwb at gmail.com>
>>>> >> >> wrote:
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> Yes, this'd be nice to have. One difficulty with arrays is that
>>>> >> >>> they
>>>> >> >>> can't be returned by value, and so the ordinary from_py_function
>>>> >> >>> mechanism (which gets called recursively) would need to be
>>>> >> >>> adapted.
>>>> >> >>> (Allowing to_py_function to be optinally be called by reference
>>>> >> >>> instead of by value could be nice as well from a performance
>>>> >> >>> standpoint.)
>>>> >> >>
>>>> >> >>
>>>> >> >> OK, thanks for the pointers.  I'll put some time on this over the
>>>> >> >> weekend.
>>>> >> >> Should I just make a PR when things are ready to review, or should
>>>> >> >> I
>>>> >> >> put up
>>>> >> >> an issue first?
>>>> >> >
>>>> >> > I think this thread is sufficient; looking forward to a pull
>>>> >> > request.
>>>> >>
>>>> >> Don't know if you had time to look at this yet,
>>>> >
>>>> >
>>>> > Yes, I've put in some time.  Initial focus is getting
>>>> >
>>>> >     cdef int a[10] = obj
>>>> >
>>>> > working, and then using that for structs.
>>>>
>>>> Sounds good.
>>>>
>>>> > Took a little while to re-orient myself with the codebase.
>>>> >
>>>> > I'm working on getting the `to_py_function` and `from_py_function`
>>>> > infrastructure to take arguments by reference; right now I'm getting
>>>> > something hacked into place, and I'd appreciate your review to point
>>>> > out the
>>>> > right way (or at least a better way) to do it.
>>>>
>>>> from_py_function always takes its argument (a PyObject*) by reference.
>>>> It's used as an rvalue, so might not make sense for arrays.
>>>
>>>
>>> My bad, I worded my response poorly -- what I mean is that currently the
>>> generated code is something like:
>>>
>>>     __pyx_v_t1 = xxx_from_py_function_xxx(temp_py_obj);
>>>
>>>     ___pyx_v_a = __pyx_v_t1;
>>>
>>> where __pyx_v_a and __pyx_v_t1 are declared as fixed-size C arrays.
>>>
>>> This won't work, for reasons pointed out.
>>>
>>> So I'm trying to generate instead:
>>>
>>>     err_code = xxx_from_py_function_xxx(temp_py_obj, &__pyx_v_a[0], 10);
>>> if (err_code == -1) { ... }
>>
>>
>> FWIW think you can just write &__pyx_v_a
>
>
> Yes, thanks, this form will also generalize to multidimensional fixed-sized
> arrays.  For that matter, we can just pass in __pyx_v_a, which is equivalent
> to either &__pyx_v_a or &__pyx_v_a[0] (K&R 5.3).
>
>>
>>
>>>
>>> Where the 10 is the array length.  The function would initialize the
>>> array internally.  The python object is passed by reference as before, and
>>> the array is also passed by reference.  The array is assigned to just once,
>>> minimizing copying.  We can return a status code to propagate errors, etc.
>>> This seems like the cleanest code to me.  Thoughts?
>>
>>
>> Yes, that makes sense.
>>
>> One of my concerns was whether xxx_from_py_function_xxx was always
>> assigned to an lvalue, enabling this transformation, but I think with error
>> checking it's always assigned to a temporary, so we're OK here.
>>
>
> Sorry, I didn't quite follow that.  The lhs is an lvalue at the C level
> already, right?  And we'd want to use the array variable directly in the
> xxx_from_py_function_xxx call, not a temporary, since the `__pyx_v_a =
> __pyx_v_t1` temp assignment won't work.  What am I missing here?

I was worried there might be a case that the return value of
xxx_from_py_function_xxx was not immediately assigned to an lvalue,
but I think that's never the case.

>> Are you thinking of transforming all xxx_from_py_function_xxx to be of
>> this form?
>
>
> No, I was thinking this would kick in for just fixed-size arrays, structs,
> and perhaps others as makes sense.  Everything else would remain as-is.
>
>>
>> It could make sense for structs, and make for cleaner error checking, but
>> would there be more overhead for simple types like converting to a long
>> (which are currently macros)?
>
>
> Agreed.  Simple types should remain as-is.
>
>>
>> If the length is an argument, would one have to check for whether to pass
>> this at every use of the from_py_function?
>
>
> No, my thinking is that this transformation (and passing in the array size)
> would only apply for fixed-size arrays.

Sounds good.

- Robert

From kwmsmith at gmail.com  Mon Jul 28 06:34:10 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Sun, 27 Jul 2014 23:34:10 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
Message-ID: <CALpTaNYj9QhVwNk1JEZgn5Sq7YdApXYZJR_6=Fuj2umfk6xPfQ@mail.gmail.com>

On Thu, Jul 24, 2014 at 9:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:

>
> I'm working on getting the `to_py_function` and `from_py_function`
> infrastructure to take arguments by reference; right now I'm getting
> something hacked into place, and I'd appreciate your review to point out
> the right way (or at least a better way) to do it.
>
> Will likely have a PR for you by this weekend.
>

Update: all the pieces are coming together.  I have sorted out all the code
generation pieces and nearly have a minimal example working, and will have
something for you to review soon.  From what I can tell, Cython has some
baked-in assumptions when it comes to assignment statements.  Telling
Cython that in this case, no, don't assign to something at the C level,
instead generate a function call and pass in the lvalue by reference takes
some doing.

I tried to fit things in with Cython's type system and pipelines, but I
have no doubt that it can be improved to do things the right way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140727/9a7b25b1/attachment.html>

From robertwb at gmail.com  Mon Jul 28 18:02:39 2014
From: robertwb at gmail.com (Robert Bradshaw)
Date: Mon, 28 Jul 2014 09:02:39 -0700
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNYj9QhVwNk1JEZgn5Sq7YdApXYZJR_6=Fuj2umfk6xPfQ@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CALpTaNYj9QhVwNk1JEZgn5Sq7YdApXYZJR_6=Fuj2umfk6xPfQ@mail.gmail.com>
Message-ID: <CADiQ+QDWe_mJPPFQV0FJO3zrRuDDNLTcPmWAv7Z-NTK72XjGoQ@mail.gmail.com>

On Sun, Jul 27, 2014 at 9:34 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
> On Thu, Jul 24, 2014 at 9:13 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>>
>>
>> I'm working on getting the `to_py_function` and `from_py_function`
>> infrastructure to take arguments by reference; right now I'm getting
>> something hacked into place, and I'd appreciate your review to point out the
>> right way (or at least a better way) to do it.
>>
>> Will likely have a PR for you by this weekend.
>
>
> Update: all the pieces are coming together.

Cool.

> I have sorted out all the code
> generation pieces and nearly have a minimal example working, and will have
> something for you to review soon.  From what I can tell, Cython has some
> baked-in assumptions when it comes to assignment statements.  Telling Cython
> that in this case, no, don't assign to something at the C level, instead
> generate a function call and pass in the lvalue by reference takes some
> doing.

Yeah, I'm not too surprised about that.

> I tried to fit things in with Cython's type system and pipelines, but I have
> no doubt that it can be improved to do things the right way.

I'll be happy to take a look.

- Robert

From stefan_ml at behnel.de  Mon Jul 28 20:15:56 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 28 Jul 2014 20:15:56 +0200
Subject: [Cython] heads-up on master branch status
In-Reply-To: <CADiQ+QD3_Y4+Vx5t3hBne5sAc+NfYSbr2GeupzdQM5h+vJTGyQ@mail.gmail.com>
References: <53C43448.8060102@behnel.de>
 <CADiQ+QD3_Y4+Vx5t3hBne5sAc+NfYSbr2GeupzdQM5h+vJTGyQ@mail.gmail.com>
Message-ID: <53D6935C.4010902@behnel.de>

Robert Bradshaw, 15.07.2014 23:13:
> On Mon, Jul 14, 2014 at 12:49 PM, Stefan Behnel wrote:
>> by applying some initially small but perpetually growing fixes, I pushed
>> myself into a corner where the only escape was to rewrite BoolBinopNode
>> (short-circuiting and/or expressions). This was long overdue anyway and
>> simply wasn't done before because it's not trivial and quite risky. I think
>> I got it working better than before, but there are still corner cases that
>> require some further fighting. One of them currently crashes the pyregr
>> tests in Py2.7 [...]
> 
> Ironically, I noticed these BoolBinop failures and started working on a fix
> myself (including side diversions like making void* the spanning type of
> all pointers) before noticing that you were on it, so I have a bit of an
> idea what a long, twisty path this starts down and can only say thanks for
> taking this on.

It looks like I got all corner cases fixed that I could find anywhere on
Jenkins (and I definitely broke enough builds along the way). That brings
master back to a state where I think we should plan for an alpha release to
get testing on user side as well.

Regarding the void* spanning type, it's currently only used for
independently inferred types for the operands of conditional and and/or
expressions. I don't see a reason not to enable it for all type inference
cases, though. Any objections to that?

Stefan


From robertwb at math.washington.edu  Mon Jul 28 20:36:44 2014
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 28 Jul 2014 11:36:44 -0700
Subject: [Cython] heads-up on master branch status
In-Reply-To: <53D6935C.4010902@behnel.de>
References: <53C43448.8060102@behnel.de>
 <CADiQ+QD3_Y4+Vx5t3hBne5sAc+NfYSbr2GeupzdQM5h+vJTGyQ@mail.gmail.com>
 <53D6935C.4010902@behnel.de>
Message-ID: <CADiQ+QDAYkHZp3DijVtE0sM=rvkwiDckOodJUOHVCW5j1LAOSw@mail.gmail.com>

On Mon, Jul 28, 2014 at 11:15 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:

> Robert Bradshaw, 15.07.2014 23:13:
> > On Mon, Jul 14, 2014 at 12:49 PM, Stefan Behnel wrote:
> >> by applying some initially small but perpetually growing fixes, I pushed
> >> myself into a corner where the only escape was to rewrite BoolBinopNode
> >> (short-circuiting and/or expressions). This was long overdue anyway and
> >> simply wasn't done before because it's not trivial and quite risky. I
> think
> >> I got it working better than before, but there are still corner cases
> that
> >> require some further fighting. One of them currently crashes the pyregr
> >> tests in Py2.7 [...]
> >
> > Ironically, I noticed these BoolBinop failures and started working on a
> fix
> > myself (including side diversions like making void* the spanning type of
> > all pointers) before noticing that you were on it, so I have a bit of an
> > idea what a long, twisty path this starts down and can only say thanks
> for
> > taking this on.
>
> It looks like I got all corner cases fixed that I could find anywhere on
> Jenkins (and I definitely broke enough builds along the way). That brings
> master back to a state where I think we should plan for an alpha release to
> get testing on user side as well.


Sound good. There's a lot of stuff in this release.


> Regarding the void* spanning type, it's currently only used for
>
independently inferred types for the operands of conditional and and/or
> expressions. I don't see a reason not to enable it for all type inference
> cases, though. Any objections to that?
>

The other case I could see it coming up is

common = some_int_ptr()
common = some_double_ptr()

Which formerly would be an error.

The C standard prohibits pointer arithmetic with void*, but gcc accepts it
(as if it were a char* IIRC). However, it can't be dereferenced without
casting to another pointer type, so it's not totally unsafe. I think it's
OK to enable everywhere, making things more consistent.

- Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140728/ea0e5a46/attachment.html>

From kwmsmith at gmail.com  Tue Jul 29 06:29:35 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Mon, 28 Jul 2014 23:29:35 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CADiQ+QDWe_mJPPFQV0FJO3zrRuDDNLTcPmWAv7Z-NTK72XjGoQ@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CALpTaNYj9QhVwNk1JEZgn5Sq7YdApXYZJR_6=Fuj2umfk6xPfQ@mail.gmail.com>
 <CADiQ+QDWe_mJPPFQV0FJO3zrRuDDNLTcPmWAv7Z-NTK72XjGoQ@mail.gmail.com>
Message-ID: <CALpTaNZ3nd878=okszUj36E8JJazc19fnFny8NW-ZCQBfJoMMw@mail.gmail.com>

On Mon, Jul 28, 2014 at 11:02 AM, Robert Bradshaw <robertwb at gmail.com>
wrote:

> On Sun, Jul 27, 2014 at 9:34 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>
> > I have sorted out all the code
> > generation pieces and nearly have a minimal example working, and will
> have
> > something for you to review soon.  From what I can tell, Cython has some
> > baked-in assumptions when it comes to assignment statements.  Telling
> Cython
> > that in this case, no, don't assign to something at the C level, instead
> > generate a function call and pass in the lvalue by reference takes some
> > doing.
>
> Yeah, I'm not too surprised about that.
>
>
I have an initial version working for assigning a Python object to a
fixed-size array.  It's special cased to C ints and pretty messy in parts,
but it gets the job done.  I have some ideas on how to generalize the
type.  Like I said, I'll need your input on the right way to do some things.

Will clean it up and put up a PR as soon as I can.

Once this is in place, assigning a dict-like object to a struct can build
on it.

There are a number of other little things that would be nice, like allowing
slice assignment:

    c_arr[5:13] = obj

and initializing a dynamic C array with a Python object, provided the
extent is specified:

    cdef int *arr = <int*>malloc(N * sizeof(int))
    arr[:N] = obj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140728/8080b98f/attachment.html>

From kwmsmith at gmail.com  Wed Jul 30 06:54:13 2014
From: kwmsmith at gmail.com (Kurt Smith)
Date: Tue, 29 Jul 2014 23:54:13 -0500
Subject: [Cython] Automatic conversion with fixed-size C arrays
In-Reply-To: <CALpTaNZ3nd878=okszUj36E8JJazc19fnFny8NW-ZCQBfJoMMw@mail.gmail.com>
References: <CALpTaNYskf94RzTExj4JEn5sO7b6ryYBhVFrFYAzxZ96R7onRg@mail.gmail.com>
 <CADiQ+QBJ_dSCXV-hVRmyqMAmhApQfVDE4B7H9DVZzP8L8N+S+A@mail.gmail.com>
 <CALpTaNb+nGeOfPgaLjsLxrWP8ug=y_2f7+uTKs5_hUQnGaWx5Q@mail.gmail.com>
 <CADiQ+QDC5SF2xRhzZCH_ufPjn_59VuJX+gVyMJpzizK+S9-zTA@mail.gmail.com>
 <CADiQ+QBwn7=_5bXAO+-3-m31LG13ASo5Df8-QWum6FhTsDpS=A@mail.gmail.com>
 <CALpTaNbF4UypSmVAATcGRiJnno7A642Nd8uAPVz25rpAELD2Ew@mail.gmail.com>
 <CALpTaNYj9QhVwNk1JEZgn5Sq7YdApXYZJR_6=Fuj2umfk6xPfQ@mail.gmail.com>
 <CADiQ+QDWe_mJPPFQV0FJO3zrRuDDNLTcPmWAv7Z-NTK72XjGoQ@mail.gmail.com>
 <CALpTaNZ3nd878=okszUj36E8JJazc19fnFny8NW-ZCQBfJoMMw@mail.gmail.com>
Message-ID: <CALpTaNZS9127ti_PPui4gJpA8tK6AHH2LpLKqXLR9HQ-uP-O1g@mail.gmail.com>

On Mon, Jul 28, 2014 at 11:29 PM, Kurt Smith <kwmsmith at gmail.com> wrote:

> On Mon, Jul 28, 2014 at 11:02 AM, Robert Bradshaw <robertwb at gmail.com>
> wrote:
>
>> On Sun, Jul 27, 2014 at 9:34 PM, Kurt Smith <kwmsmith at gmail.com> wrote:
>>
>> > I have sorted out all the code
>> > generation pieces and nearly have a minimal example working, and will
>> have
>> > something for you to review soon.  From what I can tell, Cython has some
>> > baked-in assumptions when it comes to assignment statements.  Telling
>> Cython
>> > that in this case, no, don't assign to something at the C level, instead
>> > generate a function call and pass in the lvalue by reference takes some
>> > doing.
>>
>> Yeah, I'm not too surprised about that.
>>
>>
> I have an initial version working for assigning a Python object to a
> fixed-size array.
>

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

Do you prefer that we continue discussion on this thread, or on the PR?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20140729/fb296f77/attachment.html>

From stefan_ml at behnel.de  Thu Jul 31 19:49:38 2014
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 31 Jul 2014 19:49:38 +0200
Subject: [Cython] Cython 0.21 alpha 1 released
Message-ID: <53DA81B2.10805@behnel.de>

Hi,

I uploaded a first alpha release of Cython 0.21.

http://cython.org/release/Cython-0.21a1.tar.gz

http://cython.org/release/Cython-0.21a1.tar.gz.asc


There were a couple of major changes in this version, including internal
improvements to some basic syntax structures, so please give it a try with
your code to help us fix some more bugs before the final release.

Complete changelog:

https://github.com/cython/cython/blob/deb348795f79342843e692358140ea4581985635/CHANGES.rst

Have fun,

Stefan