From robertwb at gmail.com  Thu Jan  3 21:21:10 2013
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 3 Jan 2013 12:21:10 -0800
Subject: [Cython] Cython 0.17.4 released.
Message-ID: <CADiQ+QCtZrfgqDxaZk_k_5eQn4GQyiEaHj0utpMd0qKQV2xUNg@mail.gmail.com>

I've just released Cython 0.17.4, which can be downloaded from
http://cython.org or pypi. It's a minor bug fix release, fixing a
double-allocation bug uncovered in Sage (see
https://groups.google.com/forum/?hl=en&fromgroups=#!msg/sage-devel/Wt7uxbDkh_A/4qhfm2ukBR0Jfor
more details).

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

From robertwb at gmail.com  Thu Jan  3 21:21:47 2013
From: robertwb at gmail.com (Robert Bradshaw)
Date: Thu, 3 Jan 2013 12:21:47 -0800
Subject: [Cython] releasing 0.18?
In-Reply-To: <CANg26EVDeU=qwDtyd=h11_xcpYTAeJFUs1CGb340OuZbTk_P3Q@mail.gmail.com>
References: <50CCB4A4.6040101@behnel.de>
	<CANg26EVDeU=qwDtyd=h11_xcpYTAeJFUs1CGb340OuZbTk_P3Q@mail.gmail.com>
Message-ID: <CADiQ+QBeX0oXQ0RdW=vfJBemn7wrTo4WS7gq2+mxxBK5_sb7ug@mail.gmail.com>

On Sat, Dec 15, 2012 at 4:18 PM, mark florisson
<markflorisson88 at gmail.com>wrote:

> On 15 December 2012 17:34, Stefan Behnel <stefan_ml at behnel.de> wrote:
> > Hi,
> >
> > the current master doesn't really have the one new, great&shiny feature,
> > but I don't see a reason to keep the changes back that we have
> implemented
> > so far. Robert's const support and the integer overflow checks (assuming
> > that both are ready) are certainly worth it. Unless Mark's minivect
> changes
> > are ready to merge soonish, I don't think we should keep waiting for
> them.
> >
> > So, what about getting the master ready for a release?
> >
> > Note that this means that we need a couple of more comments in the
> > changelog, as well as documentation for the things that need it (const?).
> >
> > Stefan
> > _______________________________________________
> > cython-devel mailing list
> > cython-devel at python.org
> > http://mail.python.org/mailman/listinfo/cython-devel
>
> Great. There was an issue with extension types as dtype in
> memoryviews, which I hope to have a look at tomorrow.
>

Status update?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130103/7c929b66/attachment.html>

From brad.froehle at gmail.com  Thu Jan  3 22:21:07 2013
From: brad.froehle at gmail.com (Bradley Froehle)
Date: Thu, 3 Jan 2013 13:21:07 -0800 (PST)
Subject: [Cython] Cython 0.17.4 released.
In-Reply-To: <CADiQ+QCtZrfgqDxaZk_k_5eQn4GQyiEaHj0utpMd0qKQV2xUNg@mail.gmail.com>
References: <CADiQ+QCtZrfgqDxaZk_k_5eQn4GQyiEaHj0utpMd0qKQV2xUNg@mail.gmail.com>
Message-ID: <379286ab-1a8d-41d8-b221-dce08a40e48c@googlegroups.com>

I assume 0.17.4 this corresponds to git commit 
53db1cdd9f1e2aabd066a1d7c6cd8353fe1ca920?

On Thursday, January 3, 2013 12:21:10 PM UTC-8, Robert Bradshaw wrote:
>
> I've just released Cython 0.17.4, which can be downloaded from 
> http://cython.org or pypi. It's a minor bug fix release, fixing a 
> double-allocation bug uncovered in Sage (see 
> https://groups.google.com/forum/?hl=en&fromgroups=#!msg/sage-devel/Wt7uxbDkh_A/4qhfm2ukBR0Jfor more details).
>
> - Robert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130103/46fe8d50/attachment.html>

From dieterv77 at gmail.com  Sun Jan  6 02:17:28 2013
From: dieterv77 at gmail.com (Dieter Vandenbussche)
Date: Sat, 5 Jan 2013 20:17:28 -0500
Subject: [Cython] Potential 32bit linux issue
Message-ID: <CA+zrVcxy17fo-kVncsGhoPoZaqAotSNWsM2_oVgXo7=oScdTEA@mail.gmail.com>

Hi, this is my first time posting to this list, hopefully i'm not wasting
anyone's time.

i believe i may have encountered an issue on 32bit linux using cython.

Here's a small example pyx file that illustrates the potential issue:

#Begin pyx file
cdef extern from "stdint.h":
    enum: INT64_MIN

cpdef f():
    cdef long long x = INT64_MIN
    print x
    print INT64_MIN
#End pyx file

The first print statement works as expected, the second does not (and
prints "0").  Looking at the C code that was generated, it looks like
the second print statement is resulting in a call to PyInt_FromLong, which
I believe might be the source of an overflow.

Thanks for taking the time to take a look.

dieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130105/cd09dd3b/attachment.html>

From robertwb at gmail.com  Sun Jan  6 04:26:38 2013
From: robertwb at gmail.com (Robert Bradshaw)
Date: Sat, 5 Jan 2013 19:26:38 -0800
Subject: [Cython] Potential 32bit linux issue
In-Reply-To: <CA+zrVcxy17fo-kVncsGhoPoZaqAotSNWsM2_oVgXo7=oScdTEA@mail.gmail.com>
References: <CA+zrVcxy17fo-kVncsGhoPoZaqAotSNWsM2_oVgXo7=oScdTEA@mail.gmail.com>
Message-ID: <CADiQ+QDcWzJKQcf6e0U1P9h8aAYOYSev_6aT1nscjtwQqJ-H1A@mail.gmail.com>

You ned to declare INT64_MIN as a long long. Enums are of type int.
On Jan 5, 2013 5:17 PM, "Dieter Vandenbussche" <dieterv77 at gmail.com> wrote:

> Hi, this is my first time posting to this list, hopefully i'm not wasting
> anyone's time.
>
> i believe i may have encountered an issue on 32bit linux using cython.
>
> Here's a small example pyx file that illustrates the potential issue:
>
> #Begin pyx file
> cdef extern from "stdint.h":
>     enum: INT64_MIN
>
> cpdef f():
>     cdef long long x = INT64_MIN
>     print x
>     print INT64_MIN
> #End pyx file
>
> The first print statement works as expected, the second does not (and
> prints "0").  Looking at the C code that was generated, it looks like
> the second print statement is resulting in a call to PyInt_FromLong, which
> I believe might be the source of an overflow.
>
> Thanks for taking the time to take a look.
>
> dieter
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130105/65f25943/attachment.html>

From lists at onerussian.com  Tue Jan  8 04:23:52 2013
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Mon, 7 Jan 2013 22:23:52 -0500
Subject: [Cython] Cython 0.17.2 released
In-Reply-To: <CADiQ+QDTKVY-j8vHEu1jaaJYpw2NF_ykjy4PU7Ui2PVwHqHn0w@mail.gmail.com>
References: <50ABED53.8070104@behnel.de> <20121203162320.GH7431@onerussian.com>
	<50CAD501.4050402@behnel.de>
	<20121220180218.GA17537@onerussian.com>
	<CADiQ+QDTKVY-j8vHEu1jaaJYpw2NF_ykjy4PU7Ui2PVwHqHn0w@mail.gmail.com>
Message-ID: <20130108032352.GB17537@onerussian.com>


On Thu, 20 Dec 2012, Robert Bradshaw wrote:
> >   git rev-parse HEAD

> > might be a better choice for this purpose

> > would you accept such a fix/PR ?

> Yes, please send us a fix. (This was written right when we were moving
> to git, before we knew it well.)

apparently I did! ;)
https://github.com/cython/cython/pull/173

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
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 dewachter.jonathan at gmail.com  Tue Jan  8 22:43:09 2013
From: dewachter.jonathan at gmail.com (Jonathan De Wachter)
Date: Tue, 8 Jan 2013 22:43:09 +0100
Subject: [Cython] Generate headers in a given directory ?
Message-ID: <CAEboS12xEEN7Qh=et+Q-him++jB9tuFqCH1zgV9vDZZSAeKs2w@mail.gmail.com>

Is there a way to tell Cython to generate headers (*_api.h, *.h) in a given
directory ?

For example, my project structure is as follow:

myproject/
   --include/
   --src/

And I'd like my extensions located in src/ to generate their headers in
include/.

myproject/
   --include/
   ----- mymodule_api.h
   ----- mymodule.h
   --src/
   ----- mymodule.pyx

Thanks :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130108/a79eab56/attachment.html>

From stefan_ml at behnel.de  Sun Jan 13 13:49:31 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 13 Jan 2013 13:49:31 +0100
Subject: [Cython] releasing 0.18?
In-Reply-To: <50CCB4A4.6040101@behnel.de>
References: <50CCB4A4.6040101@behnel.de>
Message-ID: <50F2AD5B.5020205@behnel.de>

Hi,

haven't heard from Mark yet, but would anyone object to releasing a beta in
a couple of days?

Stefan


From markflorisson88 at gmail.com  Sun Jan 13 21:27:43 2013
From: markflorisson88 at gmail.com (mark florisson)
Date: Sun, 13 Jan 2013 14:27:43 -0600
Subject: [Cython] releasing 0.18?
In-Reply-To: <50F2AD5B.5020205@behnel.de>
References: <50CCB4A4.6040101@behnel.de>
	<50F2AD5B.5020205@behnel.de>
Message-ID: <CANg26EW8UVK6WQz1si57Fod_d3PzdCqSTRUwb3BN4ZOzGE2Q5Q@mail.gmail.com>

On 13 January 2013 06:49, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> haven't heard from Mark yet, but would anyone object to releasing a beta in
> a couple of days?
>
> Stefan
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel

Sorry, I forgot to report back. I pushed the extension type as dtype
fix a while ago in commit 478b939a4c99a77c0863cfdedaf7cb6072b70523 . A
beta release sounds good to me.

From matthew.brett at gmail.com  Sun Jan 13 21:39:12 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sun, 13 Jan 2013 20:39:12 +0000
Subject: [Cython] Qt bindings discussion on PySide list
Message-ID: <CAH6Pt5qw0EFhMm3gDbnmSta683DSrUY=fuqvYN5a1HS06FuLKw@mail.gmail.com>

Hi,

Sorry - this is a wild question.

There's a discussion going on on the PySide mailing list about how to
get going on bindings for the new Qt5.  There is a feeling I think
that the current shiboken binding generator is not maintainable in the
current state, and there's a discussion about trying other binding
generators such as swig.

http://thread.gmane.org/gmane.comp.lib.qt.pyside/4147

I don't know anything about C++ bindings, so this question is from
complete ignorance; is there any future in discussing Cython for
bindings of a large C++ library like Qt, or is that well out of range?

Thanks a lot,

Matthew

From robertwb at gmail.com  Mon Jan 14 20:08:02 2013
From: robertwb at gmail.com (Robert Bradshaw)
Date: Mon, 14 Jan 2013 11:08:02 -0800
Subject: [Cython] releasing 0.18?
In-Reply-To: <CANg26EW8UVK6WQz1si57Fod_d3PzdCqSTRUwb3BN4ZOzGE2Q5Q@mail.gmail.com>
References: <50CCB4A4.6040101@behnel.de> <50F2AD5B.5020205@behnel.de>
	<CANg26EW8UVK6WQz1si57Fod_d3PzdCqSTRUwb3BN4ZOzGE2Q5Q@mail.gmail.com>
Message-ID: <CADiQ+QBmwAYoPNFBYsd-i2RMUNJUVrsgBbN10YkvfyOwFsFSmA@mail.gmail.com>

On Sun, Jan 13, 2013 at 12:27 PM, mark florisson
<markflorisson88 at gmail.com>wrote:

> On 13 January 2013 06:49, Stefan Behnel <stefan_ml at behnel.de> wrote:
> > Hi,
> >
> > haven't heard from Mark yet, but would anyone object to releasing a beta
> in
> > a couple of days?
> >
> > Stefan
> >
> > _______________________________________________
> > cython-devel mailing list
> > cython-devel at python.org
> > http://mail.python.org/mailman/listinfo/cython-devel
>
> Sorry, I forgot to report back. I pushed the extension type as dtype
> fix a while ago in commit 478b939a4c99a77c0863cfdedaf7cb6072b70523 . A
> beta release sounds good to me.
> <http://mail.python.org/mailman/listinfo/cython-devel>
>

Ah, excellent.

I've created a branch 0.18.x. This will save us from the pain of having
both a branch and a tag named 0.18, as well as making it clear that this is
for the entire 0.18 series. The hudson release build now points to this
branch.

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

From stefan_ml at behnel.de  Sat Jan 19 14:22:21 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 19 Jan 2013 14:22:21 +0100
Subject: [Cython] "minierror" in Shadow.py?
Message-ID: <50FA9E0D.1000407@behnel.de>

Hi,

I just wanted to release 0.18 beta1 when I noticed this code in Shadow.py,
function index_type():

"""
            raise minierror.InvalidTypeSpecification(
                "Only a step of 1 may be provided to indicate C or "
                "Fortran contiguity")
"""

There is no import "minierror" and the comments seem to indicate that this
is mostly a copy&paste oversight from code in minivect. Can this function
(and the other changes in that file that came in the same commit) be
removed from the 0.18 branch or are they needed for something?

https://github.com/cython/cython/commit/b9a2c953974c4ebc4aa37e7e64d642ce117337fb

Stefan

From markflorisson88 at gmail.com  Sat Jan 19 19:46:19 2013
From: markflorisson88 at gmail.com (mark florisson)
Date: Sat, 19 Jan 2013 12:46:19 -0600
Subject: [Cython] "minierror" in Shadow.py?
In-Reply-To: <50FA9E0D.1000407@behnel.de>
References: <50FA9E0D.1000407@behnel.de>
Message-ID: <CANg26EXV-6_deH+6wyxvJmrYk1Z9VD7ra0G40_6qgNDPVYf9EQ@mail.gmail.com>

On 19 January 2013 07:22, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I just wanted to release 0.18 beta1 when I noticed this code in Shadow.py,
> function index_type():
>
> """
>             raise minierror.InvalidTypeSpecification(
>                 "Only a step of 1 may be provided to indicate C or "
>                 "Fortran contiguity")
> """
>
> There is no import "minierror" and the comments seem to indicate that this
> is mostly a copy&paste oversight from code in minivect. Can this function
> (and the other changes in that file that came in the same commit) be
> removed from the 0.18 branch or are they needed for something?
>
> https://github.com/cython/cython/commit/b9a2c953974c4ebc4aa37e7e64d642ce117337fb
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel

Hey Stefan,

Those changes are needed to support specifying memoryviews from pure
python. This is useful for instance to select a memoryview
specialization of a def function from Python.

I think the fix is to just define that exception and remove the
reference to minierror.

Mark

From stefan_ml at behnel.de  Sat Jan 19 20:49:03 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 19 Jan 2013 20:49:03 +0100
Subject: [Cython] "minierror" in Shadow.py?
In-Reply-To: <CANg26EXV-6_deH+6wyxvJmrYk1Z9VD7ra0G40_6qgNDPVYf9EQ@mail.gmail.com>
References: <50FA9E0D.1000407@behnel.de>
	<CANg26EXV-6_deH+6wyxvJmrYk1Z9VD7ra0G40_6qgNDPVYf9EQ@mail.gmail.com>
Message-ID: <50FAF8AF.5060908@behnel.de>

mark florisson, 19.01.2013 19:46:
> On 19 January 2013 07:22, Stefan Behnel wrote:
>> I just wanted to release 0.18 beta1 when I noticed this code in Shadow.py,
>> function index_type():
>>
>> """
>>             raise minierror.InvalidTypeSpecification(
>>                 "Only a step of 1 may be provided to indicate C or "
>>                 "Fortran contiguity")
>> """
>>
>> There is no import "minierror" and the comments seem to indicate that this
>> is mostly a copy&paste oversight from code in minivect. Can this function
>> (and the other changes in that file that came in the same commit) be
>> removed from the 0.18 branch or are they needed for something?
>>
>> https://github.com/cython/cython/commit/b9a2c953974c4ebc4aa37e7e64d642ce117337fb
>
> Those changes are needed to support specifying memoryviews from pure
> python. This is useful for instance to select a memoryview
> specialization of a def function from Python.
> 
> I think the fix is to just define that exception and remove the
> reference to minierror.

Ok, done.

https://github.com/cython/cython/commit/3bd0ad9379d9eb5597494dde9377fe5b5d9e89f3

Stefan


From stefan_ml at behnel.de  Sat Jan 19 21:00:34 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 19 Jan 2013 21:00:34 +0100
Subject: [Cython] 0.18 beta 1 released
Message-ID: <50FAFB62.9050507@behnel.de>

Hi,

here's the first (and hopefully last) beta of Cython 0.18. Please give it a
try. The final release is expected to follow soon.

http://cython.org/release/Cython-0.18b1.tar.gz

http://cython.org/release/Cython-0.18b1.zip


This is a feature release with the following changes:

* Named Unicode escapes ("\N{...}") are supported.

* Python functions/classes provide the special attribute "__qualname__"
  as defined by PEP 3155.

* Added a directive ``overflowcheck`` which raises an OverflowException
  when arithmetic with C ints overflows.  This has a modest performance
  penalty, but is much faster than using Python ints.

* Calls to nested Python functions are resolved at compile time.

* Type inference works across nested functions.

* ``py_bytes_string.decode(...)`` is optimised.

* C ``const`` declarations are supported in the language.


Have fun,

Stefan

From stefan_ml at behnel.de  Sun Jan 20 07:57:33 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Jan 2013 07:57:33 +0100
Subject: [Cython] namespacing external declarations (was: [cython-users]
 Calling C++ functions without headers.)
In-Reply-To: <20130120031113.GA7071@gmail.com>
References: <20130117234736.GA21635@gmail.com>
	<CADiQ+QDhD0zNjs3yKcaSNErv9JPJKWbiwJ-NmjGaywEo5+yb4w@mail.gmail.com>
	<b706bb72-fc89-477a-a606-97496ede3f74@googlegroups.com>
	<80199742-dc98-42ee-91a9-49783580966c@googlegroups.com>
	<50F95769.3030506@behnel.de> <20130118162132.GB7031@gmail.com>
	<CADiQ+QBpXyEYtTM=4Np7cyjfNYkR0e3BXkqsHN1Q_Z3fu_8XZg@mail.gmail.com>
	<20130120031113.GA7071@gmail.com>
Message-ID: <50FB955D.9050808@behnel.de>

John Tyree, 20.01.2013 04:11:
> On Fri, Jan 18, 2013 at 10:54:24AM -0800, Robert Bradshaw wrote:
>> On Fri, Jan 18, 2013 at 8:21 AM, John Tyree wrote:
>>> There's no way to have namespaces come over with the function names is there?
>>>
>>> cdef extern from "b.cpp" namespace "foo":
>>>     void whatever()
>>>
>>> and then use foo.whatever() instead of just whatever()? I guess using a new pxd
>>> for each namespace and then cimport namespace is the best solution to that problem.
>>
>> Yep. We could consider adding a "as XXX" clause to extern inport
>> blocks as well.
>
> The as XXX alias on cdef extern from ... blocks would be seriously great. Would
> it be difficult?

I'm -0.7 on this. It would divert from Python in that you'd get yet another
way to provide a namespace inside of one source file. It won't come for
free in terms of compiler code complexity. And I don't see the big win over
having one .pxd file per namespace that you declare. That's what files are
there for, after all. And it works the same in both Python and Cython,
right now.

Stefan


From arfrever.fta at gmail.com  Sun Jan 20 13:59:03 2013
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 20 Jan 2013 13:59:03 +0100
Subject: [Cython] 0.18 beta 1 released
In-Reply-To: <50FAFB62.9050507@behnel.de>
References: <50FAFB62.9050507@behnel.de>
Message-ID: <201301201359.04383.Arfrever.FTA@gmail.com>

There are 6 test failures.
Failures in builtin_abs.__test__.int_abs might be related to new versions of GCC or glibc. I use GCC 4.7.2 and glibc 2.16.0.
Failures in NumPy-related tests are probably related to new version of NumPy. I use NumPy 1.7.0rc1.
Failures are identical with CPython 2.6, 2.7, 3.1, 3.2 and 3.3.

Results with CPython 2.7:

======================================================================
FAIL: int_abs (line 35) (builtin_abs.__test__)
Doctest: builtin_abs.__test__.int_abs (line 35)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
Failed example:
    int_abs(-max_int-1) == abs(-max_int-1)
Expected:
    True
Got:
    False


======================================================================
FAIL: int_abs (line 35) (builtin_abs.__test__)
Doctest: builtin_abs.__test__.int_abs (line 35)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
Failed example:
    int_abs(-max_int-1) == abs(-max_int-1)
Expected:
    True
Got:
    False


======================================================================
FAIL: numpy_test ()
Doctest: numpy_test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for numpy_test
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/numpy_test/numpy_test.so", line 518, in numpy_test

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/numpy_test/numpy_test.so", line 539, in numpy_test
Failed example:
    obj_array()
Expected:
    [a 1 {}]
    a 1 {}
Got:
    ['a' 1 {}]
    a 1 {}


======================================================================
FAIL: numpy_test (numpy_test.__test__)
Doctest: numpy_test.__test__.numpy_test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for numpy_test.__test__.numpy_test
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/numpy_test/numpy_test.so", line unknown line number, in numpy_test

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/numpy_test/numpy_test.so", line ?, in numpy_test.__test__.numpy_test
Failed example:
    obj_array()
Expected:
    [a 1 {}]
    a 1 {}
Got:
    ['a' 1 {}]
    a 1 {}


======================================================================
FAIL: numpy_test ()
Doctest: numpy_test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for numpy_test
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/numpy_test/numpy_test.so", line 844, in numpy_test

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/numpy_test/numpy_test.so", line 865, in numpy_test
Failed example:
    obj_array()
Expected:
    [a 1 {}]
    a 1 {}
Got:
    ['a' 1 {}]
    a 1 {}


======================================================================
FAIL: numpy_test (numpy_test.__test__)
Doctest: numpy_test.__test__.numpy_test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for numpy_test.__test__.numpy_test
  File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/numpy_test/numpy_test.so", line unknown line number, in numpy_test

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/cpp/numpy_test/numpy_test.so", line ?, in numpy_test.__test__.numpy_test
Failed example:
    obj_array()
Expected:
    [a 1 {}]
    a 1 {}
Got:
    ['a' 1 {}]
    a 1 {}


----------------------------------------------------------------------
Ran 7330 tests in 2965.935s

FAILED (failures=6)
ALL DONE

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

From cgohlke at uci.edu  Sun Jan 20 16:23:03 2013
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Sun, 20 Jan 2013 07:23:03 -0800
Subject: [Cython] 0.18 beta 1 released
In-Reply-To: <201301201359.04383.Arfrever.FTA@gmail.com>
References: <50FAFB62.9050507@behnel.de>
	<201301201359.04383.Arfrever.FTA@gmail.com>
Message-ID: <50FC0BD7.5080101@uci.edu>

On 1/20/2013 4:59 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> There are 6 test failures.
> Failures in builtin_abs.__test__.int_abs might be related to new versions of GCC or glibc. I use GCC 4.7.2 and glibc 2.16.0.
> Failures in NumPy-related tests are probably related to new version of NumPy. I use NumPy 1.7.0rc1.
> Failures are identical with CPython 2.6, 2.7, 3.1, 3.2 and 3.3.
>
<snip>

The test failures with numpy 1.7.x were reported at 
<https://github.com/numpy/numpy/issues/2870>. They are due to the 
difference in printing numpy arrays containing str objects:

# numpy 1.6.2:
>>> print(np.array(["a"], object))
[a]

# numpy 1.7.0rc1:
>>> print(np.array(["a"], object))
['a']

According to numpy developers "reprs are not required to be the same 
across numpy versions".

Christoph

From stefan_ml at behnel.de  Sun Jan 20 16:48:35 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 20 Jan 2013 16:48:35 +0100
Subject: [Cython] 0.18 beta 1 released
In-Reply-To: <201301201359.04383.Arfrever.FTA@gmail.com>
References: <50FAFB62.9050507@behnel.de>
	<201301201359.04383.Arfrever.FTA@gmail.com>
Message-ID: <50FC11D3.3030804@behnel.de>

Hi,

thanks for testing!

Arfrever Frehtes Taifersar Arahesis, 20.01.2013 13:59:
> There are 6 test failures.
> Failures in builtin_abs.__test__.int_abs might be related to new versions of GCC or glibc. I use GCC 4.7.2 and glibc 2.16.0.
> Failures in NumPy-related tests are probably related to new version of NumPy. I use NumPy 1.7.0rc1.
> Failures are identical with CPython 2.6, 2.7, 3.1, 3.2 and 3.3.
> 
> Results with CPython 2.7:
> 
> ======================================================================
> FAIL: int_abs (line 35) (builtin_abs.__test__)
> Doctest: builtin_abs.__test__.int_abs (line 35)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
>     raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
>   File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)
> 
> ----------------------------------------------------------------------
> File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
> Failed example:
>     int_abs(-max_int-1) == abs(-max_int-1)
> Expected:
>     True
> Got:
>     False

Ok, from the file system paths, this looks like 64bit Gentoo Linux.

Could you apply the attached patch and report the result for this test
again? Just pass "--no-cpp builtin_abs" to the test runner.

The test was originally written this way because the actual values change
depending on the system they run on, but it would still be good to see them
in the output in case of a failure.

Since you mentioned your recent GCC version, do you see any C compiler
warnings in the output of this particular test (i.e. during the actual test
run, not in the final summary)? Maybe with "-Wall" in your CFLAGS?

Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: abs_test.patch
Type: text/x-patch
Size: 579 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130120/1d602a77/attachment.bin>

From arfrever.fta at gmail.com  Sun Jan 20 18:07:07 2013
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 20 Jan 2013 18:07:07 +0100
Subject: [Cython] 0.18 beta 1 released
In-Reply-To: <50FC11D3.3030804@behnel.de>
References: <50FAFB62.9050507@behnel.de>
	<201301201359.04383.Arfrever.FTA@gmail.com>
	<50FC11D3.3030804@behnel.de>
Message-ID: <201301201807.09865.Arfrever.FTA@gmail.com>

2013-01-20 16:48:35 Stefan Behnel napisa?(a):
> Hi,
> 
> thanks for testing!
> 
> Arfrever Frehtes Taifersar Arahesis, 20.01.2013 13:59:
> > There are 6 test failures.
> > Failures in builtin_abs.__test__.int_abs might be related to new versions of GCC or glibc. I use GCC 4.7.2 and glibc 2.16.0.
> > Failures in NumPy-related tests are probably related to new version of NumPy. I use NumPy 1.7.0rc1.
> > Failures are identical with CPython 2.6, 2.7, 3.1, 3.2 and 3.3.
> > 
> > Results with CPython 2.7:
> > 
> > ======================================================================
> > FAIL: int_abs (line 35) (builtin_abs.__test__)
> > Doctest: builtin_abs.__test__.int_abs (line 35)
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
> >     raise self.failureException(self.format_failure(new.getvalue()))
> > AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
> >   File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)
> > 
> > ----------------------------------------------------------------------
> > File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
> > Failed example:
> >     int_abs(-max_int-1) == abs(-max_int-1)
> > Expected:
> >     True
> > Got:
> >     False
> 
> Ok, from the file system paths, this looks like 64bit Gentoo Linux.
> 
> Could you apply the attached patch and report the result for this test
> again? Just pass "--no-cpp builtin_abs" to the test runner.
> 
> The test was originally written this way because the actual values change
> depending on the system they run on, but it would still be good to see them
> in the output in case of a failure.
> 
> Since you mentioned your recent GCC version, do you see any C compiler
> warnings in the output of this particular test (i.e. during the actual test
> run, not in the final summary)? Maybe with "-Wall" in your CFLAGS?

No warnings for this particular test.

I have now tested with GCC 4.6.3 (by exporting CC="x86_64-pc-linux-gnu-gcc-4.6.3" and CXX="x86_64-pc-linux-gnu-g++-4.6.3")
and builtin_abs.__test__.int_abs tests pass with GCC 4.6.3.

Result with GCC 4.7.2 after applying your patch:

======================================================================
FAIL: int_abs (line 35) (builtin_abs.__test__)
Doctest: builtin_abs.__test__.int_abs (line 35)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
  File "/tmp/Cython-0.18b1/BUILD/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)

----------------------------------------------------------------------
File "/tmp/Cython-0.18b1/BUILD/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
Failed example:
    int_abs(-max_int-1) == abs(-max_int-1)   or (max_int, int_abs(-max_int-1), abs(-max_int-1))
Expected:
    True
Got:
    (2147483647, 18446744071562067968L, 2147483648)

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

From matej at laitl.cz  Mon Jan 21 00:16:05 2013
From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl)
Date: Mon, 21 Jan 2013 00:16:05 +0100
Subject: [Cython] Compiler crash in AnalyseDeclarationsTransform with
	binding=True
Message-ID: <1761751.NM44h0DnhH@edgy>

Heya Cython folks,
I face a compiler crash (full log at the bottom of the mail) with Cython 
0.17.1-392-g81d3d10 (today's git). This only happens if Cython directive 
binding is left to True, if set to False, the project builds and runs fine.

Steps to reproduce:
# git clone git://github.com/strohel/PyBayes.git
# cd PyBayes
# git submodule update --init
Open support/dist_cmd_build_prepare.py, set binding to True on line 35
# ./setup.py build

Note that this bug is not at all a recent regression - it exists at least 
since binding=True has been made default (commit 621dbe6403) - sorry for being 
that late reporting it.

On a related note, what does the binding directive mean? I was unable to find 
any info at [1] or [2]. What are the consequences of disabling it to work-
around this crash?

[1] http://wiki.cython.org/enhancements/compilerdirectives
[2] http://docs.cython.org/src/reference/compilation.html

Regards,
		Mat?j Laitl


=============== Full Crash Log ===============
running build_ext
cythoning pybayes/filters.py to build/temp.linux-
x86_64-2.7/pyrex/pybayes/filters.c

Error compiling Cython file:
------------------------------------------------------------
...
    cpdef Pdf posterior(self)
    cpdef double evidence_log(self, np.ndarray yt) except? -1


cdef class KalmanFilter(Filter):
    cdef readonly np.ndarray A, B, C, D, Q, R
                            ^
------------------------------------------------------------

pybayes/filters.pxd:22:29: Compiler crash in AnalyseDeclarationsTransform

ModuleNode.body = StatListNode(filters.py:13:0)
StatListNode.stats[6] = StatListNode(filters.py:62:0)
StatListNode.stats[0] = CClassDefNode(filters.py:62:0,
    base_class_name = u'Filter',
    class_name = u'KalmanFilter',
    doc = u'Implementation of standard Kalman filter. **cond** in :meth:`bayes` 
is interpreted as\n    control (intervention) input :math:`u_t` to the system.
\n\n    Kalman filter forms *optimal Bayesian solution* for the following 
system:\n\n    .. math::\n\n        x_t &= A_t x_{t-1} + B_t u_t + v_{t-1} 
\\quad \\quad\n            A_t \\in \\mathbb{R}^{n,n} \\;\\;\n            B_t 
\\in \\mathbb{R}^{n,k} \\;\\;\n            \\;\\; n \\in \\mathbb{N}\n            
\\;\\; k \\in \\mathbb{N}_0 \\text{ (may be zero)}\n            \\\\\n        
y_t &= C_t x_t + D_t u_t + w_t \\quad \\quad \\quad \\;\\;\n            C_t 
\\in \\mathbb{R}^{j,n} \\;\\;\n            D_t \\in \\mathbb{R}^{j,k} \\;\\;\n            
j \\in \\mathbb{N} \\;\\; j \\leq n\n\n    where :math:`x_t \\in 
\\mathbb{R}^n` is hidden state vector, :math:`y_t \\in \\mathbb{R}^j` is\n    
observation vector and :math:`u_t \\in \\mathbb{R}^k` is control vector. 
:math:`v_t` is normally\n    distributed zero-mean process noise with 
covariance matrix :math:`Q_t`, :math:`w_t` is normally\n    distributed zero-
mean observation noise with covariance matrix :math:`R_t`. Additionally, 
intial\n    pdf (**state_pdf**) has to be Gaussian.\n    ',
    visibility = 'private')

Compiler crash traceback from this point on:
  File "Visitor.py", line 168, in Cython.Compiler.Visitor.TreeVisitor._visit 
(/var/tmp/portage/dev-python/cython-9999/work/Cython/Compiler/Visitor.c:3840)
  File "Visitor.py", line 284, in 
Cython.Compiler.Visitor.CythonTransform.visit_Node (/var/tmp/portage/dev-
python/cython-9999/work/Cython/Compiler/Visitor.c:5756)
  File "Visitor.py", line 236, in 
Cython.Compiler.Visitor.VisitorTransform.visitchildren (/var/tmp/portage/dev-
python/cython-9999/work/Cython/Compiler/Visitor.c:4813)
  File "Visitor.py", line 210, in 
Cython.Compiler.Visitor.TreeVisitor._visitchildren (/var/tmp/portage/dev-
python/cython-9999/work/Cython/Compiler/Visitor.c:4591)
AssertionError: Cannot insert list here: body in 
<Cython.Compiler.Nodes.PropertyNode object at 0x3136550>

From stefan_ml at behnel.de  Mon Jan 21 07:59:35 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Jan 2013 07:59:35 +0100
Subject: [Cython] 0.18 beta 1 released
In-Reply-To: <201301201807.09865.Arfrever.FTA@gmail.com>
References: <50FAFB62.9050507@behnel.de>
	<201301201359.04383.Arfrever.FTA@gmail.com>
	<50FC11D3.3030804@behnel.de>
	<201301201807.09865.Arfrever.FTA@gmail.com>
Message-ID: <50FCE757.50600@behnel.de>

Arfrever Frehtes Taifersar Arahesis, 20.01.2013 18:07:
> 2013-01-20 16:48:35 Stefan Behnel napisa?(a):
>> Arfrever Frehtes Taifersar Arahesis, 20.01.2013 13:59:
>>> There are 6 test failures.
>>> Failures in builtin_abs.__test__.int_abs might be related to new versions of GCC or glibc. I use GCC 4.7.2 and glibc 2.16.0.
>>> Failures in NumPy-related tests are probably related to new version of NumPy. I use NumPy 1.7.0rc1.
>>> Failures are identical with CPython 2.6, 2.7, 3.1, 3.2 and 3.3.
>>>
>>> Results with CPython 2.7:
>>>
>>> ======================================================================
>>> FAIL: int_abs (line 35) (builtin_abs.__test__)
>>> Doctest: builtin_abs.__test__.int_abs (line 35)
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>>   File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
>>>     raise self.failureException(self.format_failure(new.getvalue()))
>>> AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
>>>   File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)
>>>
>>> ----------------------------------------------------------------------
>>> File "/var/tmp/portage/dev-python/cython-0.18_beta1-r1000/work/Cython-0.18b1/tests-2.7/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
>>> Failed example:
>>>     int_abs(-max_int-1) == abs(-max_int-1)
>>> Expected:
>>>     True
>>> Got:
>>>     False
>>
>> Ok, from the file system paths, this looks like 64bit Gentoo Linux.
>>
>> Could you apply the attached patch and report the result for this test
>> again? Just pass "--no-cpp builtin_abs" to the test runner.
>>
>> The test was originally written this way because the actual values change
>> depending on the system they run on, but it would still be good to see them
>> in the output in case of a failure.
>>
>> Since you mentioned your recent GCC version, do you see any C compiler
>> warnings in the output of this particular test (i.e. during the actual test
>> run, not in the final summary)? Maybe with "-Wall" in your CFLAGS?
> 
> No warnings for this particular test.
> 
> I have now tested with GCC 4.6.3 (by exporting CC="x86_64-pc-linux-gnu-gcc-4.6.3" and CXX="x86_64-pc-linux-gnu-g++-4.6.3")
> and builtin_abs.__test__.int_abs tests pass with GCC 4.6.3.

Thanks, I could reproduce it now.


> Result with GCC 4.7.2 after applying your patch:
> 
> ======================================================================
> FAIL: int_abs (line 35) (builtin_abs.__test__)
> Doctest: builtin_abs.__test__.int_abs (line 35)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/doctest.py", line 2201, in runTest
>     raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for builtin_abs.__test__.int_abs (line 35)
>   File "/tmp/Cython-0.18b1/BUILD/run/c/builtin_abs/builtin_abs.so", line unknown line number, in int_abs (line 35)
> 
> ----------------------------------------------------------------------
> File "/tmp/Cython-0.18b1/BUILD/run/c/builtin_abs/builtin_abs.so", line ?, in builtin_abs.__test__.int_abs (line 35)
> Failed example:
>     int_abs(-max_int-1) == abs(-max_int-1)   or (max_int, int_abs(-max_int-1), abs(-max_int-1))
> Expected:
>     True
> Got:
>     (2147483647, 18446744071562067968L, 2147483648)

This should fix it:

https://github.com/cython/cython/commit/43fe5b88813bb051e89d9be61373cdc3b098d624

Thanks again!

Stefan


From stefan_ml at behnel.de  Mon Jan 21 08:28:29 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Jan 2013 08:28:29 +0100
Subject: [Cython] Compiler crash in AnalyseDeclarationsTransform with
 binding=True
In-Reply-To: <1761751.NM44h0DnhH@edgy>
References: <1761751.NM44h0DnhH@edgy>
Message-ID: <50FCEE1D.1050104@behnel.de>

Hi,

thanks for the report.

Mat?j Laitl, 21.01.2013 00:16:
> Heya Cython folks,
> I face a compiler crash (full log at the bottom of the mail) with Cython 
> 0.17.1-392-g81d3d10 (today's git). This only happens if Cython directive 
> binding is left to True, if set to False, the project builds and runs fine.
> 
> Steps to reproduce:
> # git clone git://github.com/strohel/PyBayes.git
> # cd PyBayes
> # git submodule update --init
> Open support/dist_cmd_build_prepare.py, set binding to True on line 35
> # ./setup.py build
> 
> Note that this bug is not at all a recent regression - it exists at least 
> since binding=True has been made default (commit 621dbe6403) - sorry for being 
> that late reporting it.
> 
> On a related note, what does the binding directive mean? I was unable to find 
> any info at [1] or [2]. What are the consequences of disabling it to work-
> around this crash?
> 
> [1] http://wiki.cython.org/enhancements/compilerdirectives
> [2] http://docs.cython.org/src/reference/compilation.html

"Binding" is a historically grown name that means that Cython uses its own
Python function type instead of the one that CPython provides for C
functions. That allows Cython implemented functions to support binding as
methods in classes (thus the name), but generally provides them with a much
more Python-like function interface, e.g. for introspection.


> =============== Full Crash Log ===============
> running build_ext
> cythoning pybayes/filters.py to build/temp.linux-
> x86_64-2.7/pyrex/pybayes/filters.c
> 
> Error compiling Cython file:
> ------------------------------------------------------------
> ...
>     cpdef Pdf posterior(self)
>     cpdef double evidence_log(self, np.ndarray yt) except? -1
> 
> 
> cdef class KalmanFilter(Filter):
>     cdef readonly np.ndarray A, B, C, D, Q, R
>                             ^
> ------------------------------------------------------------
> 
> pybayes/filters.pxd:22:29: Compiler crash in AnalyseDeclarationsTransform
> [...]
> AssertionError: Cannot insert list here: body in 
> <Cython.Compiler.Nodes.PropertyNode object at 0x3136550>

I'm puzzled how this comes to be triggered by the "binding" directive.
Anyway, just as a stab in the dark, does the attached patch fix it for you?

Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: propnode_statlist.patch
Type: text/x-patch
Size: 581 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130121/7b304b43/attachment.bin>

From matej at laitl.cz  Tue Jan 22 10:29:06 2013
From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl)
Date: Tue, 22 Jan 2013 10:29:06 +0100
Subject: [Cython] Compiler crash in AnalyseDeclarationsTransform with
	binding=True
In-Reply-To: <50FCEE1D.1050104@behnel.de>
References: <1761751.NM44h0DnhH@edgy> <50FCEE1D.1050104@behnel.de>
Message-ID: <1871403.4vBZAFuE1P@edgy>

On 21.?1.?2013 Stefan Behnel wrote:
> > pybayes/filters.pxd:22:29: Compiler crash in AnalyseDeclarationsTransform
> > [...]
> > AssertionError: Cannot insert list here: body in 
> > <Cython.Compiler.Nodes.PropertyNode object at 0x3136550>
> 
> I'm puzzled how this comes to be triggered by the "binding" directive.
> Anyway, just as a stab in the dark, does the attached patch fix it for you?

With the patch filters.py compiles to .c, but perhaps incorrect code is 
generated, because gcc (4.6.3) then fails:

x86_64-pc-linux-gnu-gcc -pthread -fPIC -I/usr/lib64/python2.7/site-
packages/numpy/core/include -I/usr/include/atlas -I/usr/include/atlas -
I/usr/include/atlas -I/usr/include/python2.7 -c build/temp.linux-
x86_64-2.7/pyrex/pybayes/filters.c -o build/temp.linux-
x86_64-2.7/build/temp.linux-x86_64-2.7/pyrex/pybayes/filters.o -O2
build/temp.linux-x86_64-2.7/pyrex/pybayes/filters.c:8538:64: error: expected 
expression before ?static?
build/temp.linux-x86_64-2.7/pyrex/pybayes/filters.c:9357:68: error: expected 
expression before ?static?

This is kinda strange, see the lines of filters.c:
8525: static PyObject 
*__pyx_pf_7pybayes_7filters_26MarginalizedParticleFilter_4memp___get__(struct 
__pyx_obj_7pybayes_7filters_MarginalizedParticleFilter *__pyx_v_self) {
(...)
8535:  __pyx_L0:;
8536:  __Pyx_XGIVEREF(__pyx_r);
8537:  __Pyx_RefNannyFinishContext();
8538:  return __pyx_r;
8539:}
8540:
8541:/* Python wrapper */

The other occasion is similar, see whole filters.c at [1]. But perhaps this is 
an unrelated bug triggered by binding=True?

[1] http://www.laitl.cz/soubory/filters.c

[sorry for delays, I've first sent with filters.c attached, but the message got 
rejected due to size]

	Mat?j

From matej at laitl.cz  Tue Jan 22 18:13:03 2013
From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl)
Date: Tue, 22 Jan 2013 18:13:03 +0100
Subject: [Cython] releasing 0.18?
In-Reply-To: <CANg26EW8UVK6WQz1si57Fod_d3PzdCqSTRUwb3BN4ZOzGE2Q5Q@mail.gmail.com>
References: <50CCB4A4.6040101@behnel.de> <50F2AD5B.5020205@behnel.de>
	<CANg26EW8UVK6WQz1si57Fod_d3PzdCqSTRUwb3BN4ZOzGE2Q5Q@mail.gmail.com>
Message-ID: <4890326.Jov6T4rysm@edgy>

On 13.?1.?2013 mark florisson wrote:
> On 13 January 2013 06:49, Stefan Behnel <stefan_ml at behnel.de> wrote:
> > haven't heard from Mark yet, but would anyone object to releasing a beta
> > in a couple of days?
> 
> Sorry, I forgot to report back. I pushed the extension type as dtype
> fix a while ago in commit 478b939a4c99a77c0863cfdedaf7cb6072b70523 . A
> beta release sounds good to me.

With the bug fixed, perhaps the test-case 
https://github.com/cython/cython/pull/164 can be merged?

	Mat?j

From matej at laitl.cz  Tue Jan 22 18:35:22 2013
From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl)
Date: Tue, 22 Jan 2013 18:35:22 +0100
Subject: [Cython] `_save` was not declared when cathing C++ exceptions in
	nogil cdef function
Message-ID: <1500497.JDOJk8oPA9@edgy>

Hi again,
another minor problem I've stumbled upon - when I call an "except +" function 
in a cdef ... nogil function, gcc fails to compile the .cpp file. Perhaps a 
missing PyThreadState *_save; declaration in case of nogil functions?

Cython 0.18b1 3e37475ec5098eef2c421.

Attached patch trivially extends cpp_exceptions_nogil test to show the 
problem.

Cheers,
		Mat?j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Extend-cpp_exceptions_nogil-test-with-nogil-cdef-fun.patch
Type: text/x-patch
Size: 1361 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20130122/93143bb7/attachment.bin>

From chris.pcguy.inci at gmail.com  Thu Jan 24 15:13:37 2013
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Thu, 24 Jan 2013 15:13:37 +0100
Subject: [Cython] Feature Request: expand list/tuple in 'if (... in ...):'
	...
Message-ID: <51014191.4090101@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Subject: Feature Request: expand list/tuple in 'if (... in ...):' ...

expand list/tuple in 'if (... in ...):' on compile-time if the list/tuple contains only static values.

test1: list is expanded manually.
test2: list is not expanded.

The output of the testcase is:
test1: timediff: 0.205533
test2: timediff: 17.567185


Testcase:

from time import time

cdef tuple INT_TUPLE = (0x66, 0x67, 0x2e,
                 0x36, 0x3e, 0x26, 0x64,
                 0x65, 0xf2, 0xf3, 0xf0)

cpdef test():
    cdef unsigned int i
    cdef unsigned short j # 'unsigned char j' won't work for some reason
    cdef double start_time
    start_time = time()
    for i in range(0x50000):
        for j in range(256):
            if (j == 0x66 or j == 0x67 or j == 0x2e or j == 0x36 or j == 0x3e or j == 0x26 or j == 0x64 or j == 0x65 or j == 0xf2 or j == 0xf3 or j == 0xf0):
                pass
    print("test1: timediff: {0:f}".format(time()-start_time))
    start_time = time()
    for i in range(0x50000):
        for j in range(256):
            if (j in INT_TUPLE):
                pass
    print("test2: timediff: {0:f}".format(time()-start_time))
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRAUGQAAoJEDfL/pqB6n6NG90P/jWKAw1vjEO1cyem2teyYIce
cGWbewGJ14VJycztcnZG6XSNzIC0lLMbeu5edUwmr6ObPD0ic0ncGmuKVcsbUIHe
8JmVOgCxaTl2HnH3BNcvUHmsVeAL5PSyIOch80uOG7Nsh7OjZrQ8fAFqITGHzKy9
wb+C/pO1wF8xj+W9BJ5eYlvUYJLx/t/PZxFExrqrAGUxwlsqDqzoPbQsvvDAW1fB
JAMUCR/mLWTQhILOYd1Dvt8gw5uFaiyqqR12f3IOC7yh3xVo3qR3CKFneH4LzuXG
7h7Y8DICXG5xm++kwjBKDbNB+p0o2Z4D56TxdNETxO2vzjnrkIspNhrMpWucvWo3
Wi6qM56W9/2KSupvdpbaOpE0rS1QZxS8v04tpB19c85omCJRDTLlu7Yark7iwo9t
M+GZ0sS8CnqD1delky4T/JBT0tWMqGncXX9fWs0FNIjwOtzVY1QnsGmoEl7Sr2wG
jPZRrSr2gPoDE9J3+fvGceZF9qEPe9+PDA7boetokxvVS6+mFI3IsPc3wC50uHsz
27gnUH0WovUT7iIcxj/8NACejaaPCR6To9ozfhJbsLEh6YzQc+rQajw/Ag3jr933
LuyEK93PYAVQ2391aPBIDeBcDO0oKvy71foWV3sTTVyu7kKnPLRxtVsXbRv6cfQX
1f5O4GM8SzT1HuNvwMS6
=z5IY
-----END PGP SIGNATURE-----

From stefan_ml at behnel.de  Thu Jan 24 15:49:25 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 24 Jan 2013 15:49:25 +0100
Subject: [Cython] Feature Request: expand list/tuple in 'if (... in
 ...):' ...
In-Reply-To: <51014191.4090101@gmail.com>
References: <51014191.4090101@gmail.com>
Message-ID: <510149F5.70102@behnel.de>

[moving this to cython-users]

Christian Inci, 24.01.2013 15:13:
> Subject: Feature Request: expand list/tuple in 'if (... in ...):' ...
> 
> expand list/tuple in 'if (... in ...):' on compile-time if the list/tuple contains only static values.
> 
> test1: list is expanded manually.
> test2: list is not expanded.
> 
> The output of the testcase is:
> test1: timediff: 0.205533
> test2: timediff: 17.567185
> 
> 
> Testcase:
> 
> from time import time
> 
> cdef tuple INT_TUPLE = (0x66, 0x67, 0x2e,
>                  0x36, 0x3e, 0x26, 0x64,
>                  0x65, 0xf2, 0xf3, 0xf0)
> 
> cpdef test():
>     cdef unsigned int i
>     cdef unsigned short j # 'unsigned char j' won't work for some reason
>     cdef double start_time
>     start_time = time()
>     for i in range(0x50000):
>         for j in range(256):
>             if (j == 0x66 or j == 0x67 or j == 0x2e or j == 0x36 or j == 0x3e or j == 0x26 or j == 0x64 or j == 0x65 or j == 0xf2 or j == 0xf3 or j == 0xf0):
>                 pass
>     print("test1: timediff: {0:f}".format(time()-start_time))
>     start_time = time()
>     for i in range(0x50000):
>         for j in range(256):
>             if (j in INT_TUPLE):
>                 pass
>     print("test2: timediff: {0:f}".format(time()-start_time))

This is not an optimisation as it might render the code incorrect. How can
Cython know that you'll never change INT_TUPLE at runtime?

However, if you use a literal list or tuple in place, this already works,
i.e. the first example is equivalent to

    if j in (0x66, 0x67, 0x2e,
             0x36, 0x3e, 0x26, 0x64,
             0x65, 0xf2, 0xf3, 0xf0):

You actually get a C switch statement for it.

If you prefer keeping the set of integer values at a separate place, this
should work:

    DEF INT_TUPLE = (0x66, 0x67, 0x2e,
                     0x36, 0x3e, 0x26, 0x64,
                     0x65, 0xf2, 0xf3, 0xf0)

(mind the upper case "DEF").

Stefan

From d.s.seljebotn at astro.uio.no  Thu Jan 24 15:44:06 2013
From: d.s.seljebotn at astro.uio.no (Dag Sverre Seljebotn)
Date: Thu, 24 Jan 2013 15:44:06 +0100
Subject: [Cython] Feature Request: expand list/tuple in 'if (... in
 ...):' ...
In-Reply-To: <51014191.4090101@gmail.com>
References: <51014191.4090101@gmail.com>
Message-ID: <510148B6.9090502@astro.uio.no>

On 01/24/2013 03:13 PM, Christian Inci wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Subject: Feature Request: expand list/tuple in 'if (... in ...):' ...
>
> expand list/tuple in 'if (... in ...):' on compile-time if the list/tuple contains only static values.
>
> test1: list is expanded manually.
> test2: list is not expanded.
>
> The output of the testcase is:
> test1: timediff: 0.205533
> test2: timediff: 17.567185
>
>
> Testcase:
>
> from time import time
>
> cdef tuple INT_TUPLE = (0x66, 0x67, 0x2e,
>                   0x36, 0x3e, 0x26, 0x64,
>                   0x65, 0xf2, 0xf3, 0xf0)

How do you know that INT_TUPLE isn't reassigned to something else?

Dag Sverre

>
> cpdef test():
>      cdef unsigned int i
>      cdef unsigned short j # 'unsigned char j' won't work for some reason
>      cdef double start_time
>      start_time = time()
>      for i in range(0x50000):
>          for j in range(256):
>              if (j == 0x66 or j == 0x67 or j == 0x2e or j == 0x36 or j == 0x3e or j == 0x26 or j == 0x64 or j == 0x65 or j == 0xf2 or j == 0xf3 or j == 0xf0):
>                  pass
>      print("test1: timediff: {0:f}".format(time()-start_time))
>      start_time = time()
>      for i in range(0x50000):
>          for j in range(256):
>              if (j in INT_TUPLE):
>                  pass
>      print("test2: timediff: {0:f}".format(time()-start_time))
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRAUGQAAoJEDfL/pqB6n6NG90P/jWKAw1vjEO1cyem2teyYIce
> cGWbewGJ14VJycztcnZG6XSNzIC0lLMbeu5edUwmr6ObPD0ic0ncGmuKVcsbUIHe
> 8JmVOgCxaTl2HnH3BNcvUHmsVeAL5PSyIOch80uOG7Nsh7OjZrQ8fAFqITGHzKy9
> wb+C/pO1wF8xj+W9BJ5eYlvUYJLx/t/PZxFExrqrAGUxwlsqDqzoPbQsvvDAW1fB
> JAMUCR/mLWTQhILOYd1Dvt8gw5uFaiyqqR12f3IOC7yh3xVo3qR3CKFneH4LzuXG
> 7h7Y8DICXG5xm++kwjBKDbNB+p0o2Z4D56TxdNETxO2vzjnrkIspNhrMpWucvWo3
> Wi6qM56W9/2KSupvdpbaOpE0rS1QZxS8v04tpB19c85omCJRDTLlu7Yark7iwo9t
> M+GZ0sS8CnqD1delky4T/JBT0tWMqGncXX9fWs0FNIjwOtzVY1QnsGmoEl7Sr2wG
> jPZRrSr2gPoDE9J3+fvGceZF9qEPe9+PDA7boetokxvVS6+mFI3IsPc3wC50uHsz
> 27gnUH0WovUT7iIcxj/8NACejaaPCR6To9ozfhJbsLEh6YzQc+rQajw/Ag3jr933
> LuyEK93PYAVQ2391aPBIDeBcDO0oKvy71foWV3sTTVyu7kKnPLRxtVsXbRv6cfQX
> 1f5O4GM8SzT1HuNvwMS6
> =z5IY
> -----END PGP SIGNATURE-----
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>


From chris.pcguy.inci at gmail.com  Thu Jan 24 16:19:12 2013
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Thu, 24 Jan 2013 16:19:12 +0100
Subject: [Cython] Feature Request: expand list/tuple in 'if (... in
 ...):' ...
Message-ID: <510150F0.90009@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/24/2013 03:44 PM, Dag Sverre Seljebotn wrote:
> How do you know that INT_TUPLE isn't reassigned to something else?

On 01/24/2013 03:49 PM, Stefan Behnel wrote:
> This is not an optimisation as it might render the code incorrect. How can
> Cython know that you'll never change INT_TUPLE at runtime?

A good point. What's about something like final or const?

> However, if you use a literal list or tuple in place, this already works,
> i.e. the first example is equivalent to
> 
>     if j in (0x66, 0x67, 0x2e,
>              0x36, 0x3e, 0x26, 0x64,
>              0x65, 0xf2, 0xf3, 0xf0):
> 
> You actually get a C switch statement for it.

Thanks, this actually works. :-)

> 
> If you prefer keeping the set of integer values at a separate place, this
> should work:
> 
>     DEF INT_TUPLE = (0x66, 0x67, 0x2e,
>                      0x36, 0x3e, 0x26, 0x64,
>                      0x65, 0xf2, 0xf3, 0xf0)
> 
> (mind the upper case "DEF").

But this doesn't work. That's why I'm using 'cdef tuple'.

According to 'http://docs.cython.org/src/userguide/language_basics.html#compile-time-definitions', this will only work using int, long, float or str.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRAVDuAAoJEDfL/pqB6n6NsCYP/1HgWbMRuSi4o5o0gIxeSpfl
hkesrLlKe3sodTsWt3cSPGWBg5Y1pq25SUSCLCNssJruXTZ66FCTyMffc3TpEuei
PUSKq+byFplYEmCMPEm1l2z2vBI4+c5JggcXwDLlmp9RR6ZWXft0tb6fg/4Tqwyf
76/l6jrJiI7DImeJwHKDfSs1bHWCIZYPIjQWkeC42kETFG1G+U/L7tfZ8+7oq0pN
fXhRn+XK2ax3iMsswzgIBAuyywASvT2uqMI3/G+MnD7tCiRFZkzILEa3+igxqMYN
H/C9N33XLPZ1UulX40c88LHe1i2fpLvu1IvWoYc42Tszkd8Wd+uASs78b1puFTk+
jeeBLQkGbMle+eCXWQLfnSdmvvn3yYdE1UgVxQ4RXONjol9PSI1r86xn2V97phmW
C/t4r6174hv49wAG1MoMVwXOUJH3ylEBz2qJFq06nwKAU7891dd9O1tXvoVsTihe
NYDk6zflZlPZi7FUMs66S//rYYrXY/ZkA3/NhD9Krbd/Z1cVFTN1J/ynoccMx8dY
pjRz9A+oIzXw/6kvITmGx22iKZRSlhLYe32ZT1qiGk8N1nGAvlaVIqK9mpeQhECX
5CEPSj4+t6T7th7Nh/fMOqJomf0AfzCsuz4QYlYQ8Y+7zfwuOnC8AkkoIid6ac1e
M4vXi93fgnp64RpxKkxS
=Lgq1
-----END PGP SIGNATURE-----

From stefan_ml at behnel.de  Thu Jan 24 16:32:08 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 24 Jan 2013 16:32:08 +0100
Subject: [Cython] Feature Request: expand list/tuple in 'if (... in
 ...):' ...
In-Reply-To: <510150F0.90009@gmail.com>
References: <510150F0.90009@gmail.com>
Message-ID: <510153F8.5090705@behnel.de>

Christian Inci, 24.01.2013 16:19:
> On 01/24/2013 03:49 PM, Stefan Behnel wrote:
>> If you prefer keeping the set of integer values at a separate place, this
>> should work:
> 
>>     DEF INT_TUPLE = (0x66, 0x67, 0x2e,
>>                      0x36, 0x3e, 0x26, 0x64,
>>                      0x65, 0xf2, 0xf3, 0xf0)
> 
>> (mind the upper case "DEF").
> 
> According to 'http://docs.cython.org/src/userguide/language_basics.html#compile-time-definitions', this will only work using int, long, float or str.

Makes sense. It should be doable to make this work by copying AST nodes
around instead of their evaluated Python values. Doesn't sound all that
difficult.

Stefan

From matej at laitl.cz  Sat Jan 26 13:24:57 2013
From: matej at laitl.cz (=?utf-8?B?TWF0xJtq?= Laitl)
Date: Sat, 26 Jan 2013 13:24:57 +0100
Subject: [Cython] `_save` was not declared when cathing C++ exceptions
	in nogil cdef function
In-Reply-To: <1500497.JDOJk8oPA9@edgy>
References: <1500497.JDOJk8oPA9@edgy>
Message-ID: <1413640.oOAsfV4Ff8@edgy>

On 22.?1.?2013 Mat?j Laitl wrote:
> Hi again,
> another minor problem I've stumbled upon - when I call an "except +"
> function  in a cdef ... nogil function, gcc fails to compile the .cpp file.
> Perhaps a missing PyThreadState *_save; declaration in case of nogil
> functions?

Okay, I think I've found the cause, see 
https://github.com/cython/cython/pull/178

Beware that I'm rather new to Cython development, so the patch may be rather 
off, but it fixes the problem for me. :-)

Cheers,
			Mat?j

From stefan_ml at behnel.de  Sun Jan 27 13:43:27 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 27 Jan 2013 13:43:27 +0100
Subject: [Cython] http://docs.cython.org/dev/
Message-ID: <510520EF.7090902@behnel.de>

Hi,

I set up a redirect from

http://docs.cython.org/dev/

to the latest docs page built by Jenkins. Certainly easier to remember than
the lengthy real URL.

If anyone has a good idea where to show that link in the original
(released) documentation, or how to make Sphinx insert it for us, I'd be
happy to hear about it. A pull request would be well appreciated. :)

Stefan

From stefan_ml at behnel.de  Sun Jan 27 13:53:49 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 27 Jan 2013 13:53:49 +0100
Subject: [Cython] 0.18 rc1 released
Message-ID: <5105235D.60508@behnel.de>

Hi,

here is a release candidate for 0.18.

http://www.cython.org/release/Cython-0.18rc1.tar.gz

http://www.cython.org/release/Cython-0.18rc1.zip

The changes since the beta version were mostly fixes for the bugs reported
so far. Please give it another try, also to see if we managed to fix what
you found.

Thanks!

Stefan

From arfrever.fta at gmail.com  Mon Jan 28 17:42:21 2013
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Jan 2013 17:42:21 +0100
Subject: [Cython] 0.18 rc1 released
In-Reply-To: <5105235D.60508@behnel.de>
References: <5105235D.60508@behnel.de>
Message-ID: <201301281742.22745.Arfrever.FTA@gmail.com>

2013-01-27 13:53:49 Stefan Behnel napisa?(a):
> here is a release candidate for 0.18.
> 
> http://www.cython.org/release/Cython-0.18rc1.tar.gz
> 
> http://www.cython.org/release/Cython-0.18rc1.zip
> 
> The changes since the beta version were mostly fixes for the bugs reported
> so far. Please give it another try, also to see if we managed to fix what
> you found.

All tests now pass with Python 2.6, 2.7, 3.1, 3.2 and 3.3.

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

From stefan_ml at behnel.de  Tue Jan 29 07:32:17 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 29 Jan 2013 07:32:17 +0100
Subject: [Cython] Cython 0.18 released
Message-ID: <51076CF1.8090706@behnel.de>

Hi all,

Cython 0.18 is out of the door. This is a feature release that adds some
long requested language features (const!), better Python compatibility and
optimisations.

You can get it from here:

http://cython.org/release/Cython-0.18.tar.gz

http://cython.org/release/Cython-0.18.zip

Release notes: https://github.com/cython/cython/blob/0.18/CHANGES.rst

Documentation: http://docs.cython.org/


The major new features are:

* A new directive ``overflowcheck`` which raises an OverflowException
  when arithmetic with C ints overflows.  This has a modest performance
  penalty, but is much faster than using Python ints.

* C ``const`` declarations are supported in the language.

* Calls to nested Python functions are resolved at compile time.

* Type inference works across nested functions.

* ``py_bytes_string.decode(...)`` is optimised.

* Named Unicode escapes ("\N{...}") are supported.

* Python functions/classes provide the special attribute "__qualname__"
  as defined by PEP 3155.


Have fun,

Stefan

From stefan_ml at behnel.de  Tue Jan 29 22:00:05 2013
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 29 Jan 2013 22:00:05 +0100
Subject: [Cython] [cython-users] Nightly builds in "Kivy Daily" PPA
In-Reply-To: <a41b539b-ae7b-41cf-830a-863df3a7198e@googlegroups.com>
References: <a41b539b-ae7b-41cf-830a-863df3a7198e@googlegroups.com>
Message-ID: <51083855.7010407@behnel.de>

Thomas Pietrowski, 29.01.2013 20:54:
> As I'm packaging for the Kivy team and we needed updated packages for 
> Cython I made nightly builds using recipes at launchpad.
> Which means everytime you, the cython devs, commit changes at github a 
> package gets build in our PPA.
> 
> https://launchpad.net/~kivy-team/+archive/kivy-daily
> 
> We had the discussion before and I would be happy I you agree to add a PPA 
> to your team at launchpad and get these packages built there.
> I would of course help you getting it work, I just need a PPA in the team 
> to target the recipes to get built there.

I have no experience with this, but I just created a new PPA called
"master-ppa".

https://launchpad.net/~cython-dev/+archive/master-ppa

If there's anything else I have to do, just let me know.

Stefan


From golgauthic at yahoo.fr  Thu Jan 31 17:38:12 2013
From: golgauthic at yahoo.fr (g b)
Date: Thu, 31 Jan 2013 16:38:12 +0000 (GMT)
Subject: [Cython] embedsignature issue (with both Sphinx and Epydoc)
Message-ID: <1359650292.60073.YahooMailNeo@web133006.mail.ir2.yahoo.com>



Hello,

I tried the "embedsignature=True" compilation directive on both Sphinx and Epydoc and it resulted in :
I had to pass a more python compliant signature in the very first line of the docstring for each method of my classes.
See this thread : http://stackoverflow.com/questions/14616882/how-to-make-epydoc-show-parameters-in-function-prototype/14617794#14617794.

Exported signature is of the form : PyLabNode.SetNetwork(self, PyLabNetwork net) 
This has 2 drawback : The dotted notation for the class prefix and the typed parameter.

It seems to me that its feature doesn't do what it was designed for. Or I'm I missing something...

Thanks.


From sturla at molden.no  Thu Jan 31 21:31:49 2013
From: sturla at molden.no (Sturla Molden)
Date: Thu, 31 Jan 2013 21:31:49 +0100
Subject: [Cython] [cython-users] Recommendations for efficient typed
 arrays in Cython?
In-Reply-To: <4cf979ef-8684-4438-912e-4680afb01808@googlegroups.com>
References: <f5cfcb14-ab48-4d3f-abea-e9a581de9df6@googlegroups.com>
	<5107E786.7040202@molden.no>
	<CADiQ+QDAH+WWVVKHhk77dMPvd7htggLWUs=1wGGfmgsjfkdhEg@mail.gmail.com>
	<4cf979ef-8684-4438-912e-4680afb01808@googlegroups.com>
Message-ID: <510AD4B5.9000600@molden.no>

On 29.01.2013 22:15, Sal wrote:

> I don't have any 'typical' Python code yet, everything is 'cdef' type
> stuff, but reference counting is still performed by Cython on 'cdef'
> types, so sticking them into a C++ array probably ignores that fact.

I think the main difficulty with Cython (for beginners at least) is 
knowing 'when we are in C land' and 'when we are in Python land'. I 
think this is the fundamental problem you are facing here.

I therefore think it is is unfortunate that we write

   cdef object a
   cdef list b
   cdef foobar c

etc to define Python variables. 'cdef' seems to indicate that it is a C 
declaration, yet here it is not.

Neither does this cdef syntax allow us to declare Python int and float 
statically.

Perhaps it would be easier if Python variables were declared with 
'pydef'? Or perhaps just 'def'?

Then it might be easier to see what is Python and what is C.


Sturla