Re: [Cython] Any news from the IronPython port?
Hi, On Mon, Jul 18, 2011 at 3:45 PM, Jason McCampbell wrote: > Hi Stefan, > Definitely not buried for good, though we haven't made a lot of changes > recently. :) We used it for porting SciPy to .NET and re-wrote a large > number of the SciPy C module implementations in Cython. That sounds very useful. Can these re-writings be proposed as merges into the scipy tree? Did you have time to benchmark the implementations? Thanks a lot, Matthew ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.17
Hi, On Sun, May 6, 2012 at 7:28 AM, mark florisson wrote: > Hey, > > I think we already have quite a bit of functionality (nearly) ready, > after merging some pending pull requests maybe it will be a good time > for a 0.17 release? I think it would be good to also document to what > extent pypy support works, what works and what doesn't. Stefan, since > you added a large majority of the features, would you want to be the > release manager? > > In summary, the following pull requests should likely go in > - array.array support (unless further discussion prevents that) > - fused types runtime buffer dispatch > - newaxis > - more? > > The memoryview documentation should also be reworked a bit. Matthew, > are you still willing to have a go at that? Otherwise I can clean up > the mess first, some things are no longer true and simply outdated, > and then have a second opinion. Yes, sorry, I have been taken up by releasing my own project. What's the deadline do you think? I have another big release to do for the end of next week, but I might be able to carve out some time, See you, Matthew ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.17
Hi, For the promised memoryview doc edits: Sorry - I'm in Cuba - not much internet. I will push something for review by Friday, but please go ahead without me if that's not fast enough. Sorry to be the blocker, Best, Matthew On 5/23/12, mark florisson wrote: > On 23 May 2012 12:31, Robert Bradshaw wrote: >> On Tue, May 22, 2012 at 6:08 AM, mark florisson >> wrote: >>> On 6 May 2012 15:28, mark florisson wrote: Hey, I think we already have quite a bit of functionality (nearly) ready, after merging some pending pull requests maybe it will be a good time for a 0.17 release? I think it would be good to also document to what extent pypy support works, what works and what doesn't. Stefan, since you added a large majority of the features, would you want to be the release manager? In summary, the following pull requests should likely go in - array.array support (unless further discussion prevents that) - fused types runtime buffer dispatch - newaxis - more? The memoryview documentation should also be reworked a bit. Matthew, are you still willing to have a go at that? Otherwise I can clean up the mess first, some things are no longer true and simply outdated, and then have a second opinion. Mark >>> >>> I think we have enough stuff in to go for a 0.17 release, I have a few >>> more fixes and a refactoring that I'll finish tonight that might be >>> useful to get in as well. Currently Jenkins is yellow though, as the >>> reduce_pickle test fails in Python 3. >> >> I pushed a fix to the pickle tests. I've got some minor cythonize >> optimizations I'd like to get in for >> Sage as well. I'll push when I confirm thy don't break anything on >> jenkins. >> >> - Robert >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel > > Great, thanks for fixing it! Ok, let's wait for those things, and we > still also need to fix the memoryview documentation, and then we're > good to go I think :). > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.17
Hi, For the promised memoryview doc edits: Sorry - I'm in Cuba - not much internet. I will push something for review by Friday, but please go ahead without me if that's not fast enough. Sorry to be the blocker, Best, Matthew On 5/23/12, Matthew Brett wrote: > Hi, > > For the promised memoryview doc edits: > > Sorry - I'm in Cuba - not much internet. I will push something for > review by Friday, but please go ahead without me if that's not fast > enough. Sorry to be the blocker, > > Best, > > Matthew > > > On 5/23/12, mark florisson wrote: >> On 23 May 2012 12:31, Robert Bradshaw wrote: >>> On Tue, May 22, 2012 at 6:08 AM, mark florisson >>> wrote: >>>> On 6 May 2012 15:28, mark florisson wrote: >>>>> Hey, >>>>> >>>>> I think we already have quite a bit of functionality (nearly) ready, >>>>> after merging some pending pull requests maybe it will be a good time >>>>> for a 0.17 release? I think it would be good to also document to what >>>>> extent pypy support works, what works and what doesn't. Stefan, since >>>>> you added a large majority of the features, would you want to be the >>>>> release manager? >>>>> >>>>> In summary, the following pull requests should likely go in >>>>> - array.array support (unless further discussion prevents that) >>>>> - fused types runtime buffer dispatch >>>>> - newaxis >>>>> - more? >>>>> >>>>> The memoryview documentation should also be reworked a bit. Matthew, >>>>> are you still willing to have a go at that? Otherwise I can clean up >>>>> the mess first, some things are no longer true and simply outdated, >>>>> and then have a second opinion. >>>>> >>>>> Mark >>>> >>>> I think we have enough stuff in to go for a 0.17 release, I have a few >>>> more fixes and a refactoring that I'll finish tonight that might be >>>> useful to get in as well. Currently Jenkins is yellow though, as the >>>> reduce_pickle test fails in Python 3. >>> >>> I pushed a fix to the pickle tests. I've got some minor cythonize >>> optimizations I'd like to get in for >>> Sage as well. I'll push when I confirm thy don't break anything on >>> jenkins. >>> >>> - Robert >>> ___ >>> cython-devel mailing list >>> cython-devel@python.org >>> http://mail.python.org/mailman/listinfo/cython-devel >> >> Great, thanks for fixing it! Ok, let's wait for those things, and we >> still also need to fix the memoryview documentation, and then we're >> good to go I think :). >> ___ >> cython-devel mailing list >> cython-devel@python.org >> http://mail.python.org/mailman/listinfo/cython-devel >> > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] 0.17
Hey, On Wed, May 23, 2012 at 9:35 PM, mark florisson wrote: > Hey Matthew, > > Seriously, no problem, we're still getting stuff in there, no need to > hurry. If you're in Cuba it sounds like you have better stuff to do > than improve Cython's documentation :) Not to discourage contributors, > but I would really enjoy Cuba here :). I'm working on my gsoc now, so > making some time free for me is no problem here. > > So I propose I just clean up my mess, post back a link to the > documentation, and then anyone who is interested can comment on > improvements. Thank you - well - why don't I aim for a push tomorrow, and if that get's derailed by Cuba-related things, then, I bow to your kind waiver, with thanks. See you, Matthew ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] In-place division in memoryview, ndarray causes compiler error
Hi,
For this file:
def div1(int[:] A):
A[0] /= 1
or this one:
def div2(object[int, ndim=1] A):
A[0] /= 1
I get:
File
"/Users/mb312/usr/local/lib/python2.7/site-packages/Cython/Compiler/Nodes.py",
line 354, in generate_execution_code
stat.generate_execution_code(code)
File
"/Users/mb312/usr/local/lib/python2.7/site-packages/Cython/Compiler/Nodes.py",
line 4536, in generate_execution_code
if c_op in ('/', '%') and self.lhs.type.is_int and not
code.directives['cdivision']:
AttributeError: 'CCodeWriter' object has no attribute 'directives
This is only for in-place division. I'm using current trunk:
Cython version 0.17b2
Cheers,
Matthew
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Qt bindings discussion on PySide list
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 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Travis-ci builds of OSX wheels
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@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Travis-ci builds of OSX wheels
On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw wrote: > Sure! > > On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett 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 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Travis-ci builds of OSX wheels
Hi, On Sun, Jul 6, 2014 at 1:31 AM, Robert Bradshaw wrote: > On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett wrote: >> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw wrote: >>> Sure! >>> >>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett >>> 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 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Test/example for cpdef enum
On Sat, Aug 02, 2014 at 10:08 AM, Robert Bradshaw wrote: > from: Robert Bradshaw > date: Sat, Aug 02 10:08 AM -07:00 2014 > to: Core developer mailing list of the Cython compiler > > reply-to: Core developer mailing list of the Cython compiler > > subject: Re: [Cython] Test/example for cpdef enum > > On Sat, Aug 2, 2014 at 3:56 AM, Ian Bell wrote: >> Are there any tests/docs/examples showing how to use the cpdef enum? This >> is a feature I have been looking for for a long time and I am hoping to use >> it very soon in my own project. > > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pyx > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pxd > >> I have a windows box that I can run the alpha test suite on with the full >> complement of python versions. Let me know if there is interest and I can >> run the tests. Alternatively, if you are still doing a buildbot (the link >> at https://github.com/cython/cython/wiki/HackerGuide#buildbot is broken) , >> we could configure a nightly slave to run the tests. > > That would be nice; windows is woefully undertested for Cython. Another big 'that would be nice' from me. We (the berkeley / nipy team) have a buildbot set up you could hook into if you need one. The configuration is all on github at https://github.com/nipy/nibotmi , and you are welcome to access to the build master to play with configuration if you'd like. Cheers, Matthew -- Sent from Vmail ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Test/example for cpdef enum
Hi, On Mon, Aug 4, 2014 at 4:11 PM, Ian Bell wrote: > > > > On Sat, Aug 2, 2014 at 7:42 PM, Matthew Brett > wrote: >> >> On Sat, Aug 02, 2014 at 10:08 AM, Robert Bradshaw >> wrote: >> >> > from: Robert Bradshaw >> > date: Sat, Aug 02 10:08 AM -07:00 2014 >> > to: Core developer mailing list of the Cython compiler >> > >> > reply-to: Core developer mailing list of the Cython compiler >> > >> > subject: Re: [Cython] Test/example for cpdef enum >> > >> > On Sat, Aug 2, 2014 at 3:56 AM, Ian Bell wrote: >> >> Are there any tests/docs/examples showing how to use the cpdef enum? >> >> This >> >> is a feature I have been looking for for a long time and I am hoping to >> >> use >> >> it very soon in my own project. >> > >> > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pyx >> > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pxd >> > >> >> I have a windows box that I can run the alpha test suite on with the >> >> full >> >> complement of python versions. Let me know if there is interest and I >> >> can >> >> run the tests. Alternatively, if you are still doing a buildbot (the >> >> link >> >> at https://github.com/cython/cython/wiki/HackerGuide#buildbot is >> >> broken) , >> >> we could configure a nightly slave to run the tests. >> > >> > That would be nice; windows is woefully undertested for Cython. >> >> Another big 'that would be nice' from me. >> >> We (the berkeley / nipy team) have a buildbot set up you could hook into >> if you need one. The configuration is all on github at >> https://github.com/nipy/nibotmi , and you are welcome to access to the >> build master to play with configuration if you'd like. >> > Can you set me up a nightly build (once per 24 hours) and we can then > iterate on getting things functional on my box to the level that is needed. > I use anaconda for instance which might cause issues - I briefly saw you use > virtualenv. Yes, the classes I wrote to make making a build factor a little more automated use virtualenvs; if you don't want to use those classes, you can use the bare-metal buildbot build steps with Ananconda on the slave. But - do you need Anaconda to set up a Cython build test? Maybe you can use virtualenv with the Anaconda Python? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Test/example for cpdef enum
On Mon, Aug 4, 2014 at 4:19 PM, Ian Bell wrote: > > > > On Tue, Aug 5, 2014 at 1:16 AM, Matthew Brett > wrote: >> >> Hi, >> >> On Mon, Aug 4, 2014 at 4:11 PM, Ian Bell wrote: >> > >> > >> > >> > On Sat, Aug 2, 2014 at 7:42 PM, Matthew Brett >> > wrote: >> >> >> >> On Sat, Aug 02, 2014 at 10:08 AM, Robert Bradshaw >> >> wrote: >> >> >> >> > from: Robert Bradshaw >> >> > date: Sat, Aug 02 10:08 AM -07:00 2014 >> >> > to: Core developer mailing list of the Cython compiler >> >> > >> >> > reply-to: Core developer mailing list of the Cython compiler >> >> > >> >> > subject: Re: [Cython] Test/example for cpdef enum >> >> > >> >> > On Sat, Aug 2, 2014 at 3:56 AM, Ian Bell >> >> > wrote: >> >> >> Are there any tests/docs/examples showing how to use the cpdef enum? >> >> >> This >> >> >> is a feature I have been looking for for a long time and I am hoping >> >> >> to >> >> >> use >> >> >> it very soon in my own project. >> >> > >> >> > >> >> > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pyx >> >> > >> >> > https://github.com/cython/cython/blob/master/tests/run/cpdef_enums.pxd >> >> > >> >> >> I have a windows box that I can run the alpha test suite on with the >> >> >> full >> >> >> complement of python versions. Let me know if there is interest and >> >> >> I >> >> >> can >> >> >> run the tests. Alternatively, if you are still doing a buildbot >> >> >> (the >> >> >> link >> >> >> at https://github.com/cython/cython/wiki/HackerGuide#buildbot is >> >> >> broken) , >> >> >> we could configure a nightly slave to run the tests. >> >> > >> >> > That would be nice; windows is woefully undertested for Cython. >> >> >> >> Another big 'that would be nice' from me. >> >> >> >> We (the berkeley / nipy team) have a buildbot set up you could hook >> >> into >> >> if you need one. The configuration is all on github at >> >> https://github.com/nipy/nibotmi , and you are welcome to access to the >> >> build master to play with configuration if you'd like. >> >> >> > Can you set me up a nightly build (once per 24 hours) and we can then >> > iterate on getting things functional on my box to the level that is >> > needed. >> > I use anaconda for instance which might cause issues - I briefly saw you >> > use >> > virtualenv. >> >> Yes, the classes I wrote to make making a build factor a little more >> automated use virtualenvs; if you don't want to use those classes, you >> can use the bare-metal buildbot build steps with Ananconda on the >> slave. But - do you need Anaconda to set up a Cython build test? >> Maybe you can use virtualenv with the Anaconda Python? >> > So far as I can tell, anaconda and virtualenv don't play too well together. > Which is too bad, because I recall having some issues with something > (buildbot?) not running happily in an anaconda env Maybe it's worth giving it a shot and see if problems arise? Am I right in thinking you can install Python.org Python alongside Anaconda? Maybe you could do that? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Travis-ci builds of OSX wheels
Hi, On Sat, Jul 5, 2014 at 6:37 PM, Robert Bradshaw wrote: > On Sat, Jul 5, 2014 at 6:27 PM, Matthew Brett wrote: >> Hi, >> >> On Sun, Jul 6, 2014 at 1:31 AM, Robert Bradshaw wrote: >>> On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett >>> wrote: >>>> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw wrote: >>>>> Sure! >>>>> >>>>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett >>>>> 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. Actually, I've since found (I believe) a better way of doing this, which allows me to keep updating the build system as travis changes, and that is to house the wheel building at the MacPython organization, and give y'all admin access to the repo so you can push and trigger builds as necessary. New version of repo here: https://github.com/MacPython/cython-wheels New builds of Cython 0.21 here: http://wheels.scikit-image.org/ I've sent admin invites for this repo to you (Robert) and Stefan (I think) - y'all can invite more people if you like. As usual, pressing the rebuild button on the travis page: https://travis-ci.org/MacPython/cython-wheels will (by default) trigger a build of the latest tagged version, Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Travis-ci builds of OSX wheels
On Thu, Oct 16, 2014 at 3:03 PM, Robert Bradshaw wrote: > Thanks. > > On Thu, Oct 16, 2014 at 1:46 PM, Matthew Brett > wrote: >> >> Hi, >> >> On Sat, Jul 5, 2014 at 6:37 PM, Robert Bradshaw >> wrote: >> > On Sat, Jul 5, 2014 at 6:27 PM, Matthew Brett >> > wrote: >> >> Hi, >> >> >> >> On Sun, Jul 6, 2014 at 1:31 AM, Robert Bradshaw >> >> wrote: >> >>> On Fri, Jul 4, 2014 at 3:04 PM, Matthew Brett >> >>> wrote: >> >>>> On Fri, Jul 4, 2014 at 5:51 AM, Robert Bradshaw >> >>>> wrote: >> >>>>> Sure! >> >>>>> >> >>>>> On Thu, Jul 3, 2014 at 3:49 AM, Matthew Brett >> >>>>> 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. >> >> Actually, I've since found (I believe) a better way of doing this, >> which allows me to keep updating the build system as travis changes, >> and that is to house the wheel building at the MacPython organization, >> and give y'all admin access to the repo so you can push and trigger >> builds as necessary. >> >> New version of repo here: >> >> https://github.com/MacPython/cython-wheels >> >> New builds of Cython 0.21 here: >> >> http://wheels.scikit-image.org/ >> >> I've sent admin invites for this repo to you (Robert) and Stefan (I >> think) - y'all can invite more people if you like. >> >> As usual, pressing the rebuild button on the travis page: >> >> https://travis-ci.org/MacPython/cython-wheels >> >> will (by default) trigger a build of the latest tagged version, By the way - if you would consider giving me access to Cython pypi, I am very happy to upload these wheels, Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython sometimes fails to build on Travis
Hi, On Sat, Nov 8, 2014 at 11:59 AM, Stefan Behnel wrote: > Yury V. Zaytsev schrieb am 08.11.2014 um 18:55: >> On Sat, 2014-11-08 at 00:53 +0100, Stefan Behnel wrote: >>> >>> Also, compiling the resulting C code with CFLAGS="-O0" (or "-O0 -ggdb" >>> etc.) usually gives another speed boost for testing purposes. >> >> Just to mention it, the compilation is certainly going to be much >> faster, but the resulting code might end up being a lot slower, so if >> you then run a battery of tests that uses the module, you might end up >> loosing way more than you gained by cutting down the compilation time. > > My assumption was that the test suite doesn't include performance tests and > that it is small and concise enough to exercise most code paths only a > couple of times, with only some core code paths being heavily used. That > tends to be reasonable (I've yet to see a code base with a branch coverage > of 100%), but will obviously not apply to all packages. If you have test > for large data sets, for example, the performance may suffer noticeably, as > you say. > > It's usually worth comparing, though. I have the same build error on a real machine: http://nipy.bic.berkeley.edu/builders/dipy-py3.4/builds/49/steps/shell_5/logs/stdio Is there anything you can suggest to help debug? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compilation failes if a class member is named "INFINITY"
Hi,
On Fri, Jan 30, 2015 at 1:49 AM, Michael wrote:
> Hello,
>
> if I try to compile the following minimal example:
>
> cdef class Test:
>
> cdef readonly int INFINITY
>
> cython does not complain but gcc refuses with an error message:
> In file included from /usr/include/math.h:38:0,
> from /usr/include/python2.7/pyport.h:325,
> from /usr/include/python2.7/Python.h:58,
> from testinf.c:16:
> testinf.c:433:7: error: field '__builtin_inff' declared as a function
>int INFINITY;
>^
> testinf.c: In function '__pyx_pf_7testinf_4Test_8INFINITY___get__':
> testinf.c:569:50: error: expected identifier before '(' token
>__pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->INFINITY); if
> (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 10;
> __pyx_clineno = __LINE__; goto __pyx_L1_error;}
> ^
> Apparently the name "INFINITY" is handled wrongly; any other variable
> name seems to be fine.
Maybe you hit the INFINITY gcc macro?
http://www.gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
Cheers,
Matthew
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] New hosting
Hi, On Mon, Apr 27, 2015 at 11:56 AM, Stefan Behnel wrote: > Robert Bradshaw schrieb am 27.04.2015 um 20:15: >> We also have travis.ci, >> which isn't as configurable as jenkins, but may be good enough. (The >> biggest deficiency is that it probably wouldn't allow for building and >> testing Sage regularly, or benchmarks, this is the one thing that we >> may need to find/provide custom hosting for.) > > ... and it won't easily allow us to track the CPython development branches > and build against them. A really neat feature of our Jenkins server was > that it could nicely store away pre-built artefacts for later reuse on the > same machine, such as a series of CPython branch builds, and just happily > rebuilt them regularly on external changes. That totally helped spotting > integration problems as early as possible, including bugs on both sides. Some of us use scikit-learn's rackspace account for that. I'm sure if you ask Olivier Grisel nicely, from scikit-learn - he'd let you use it too. We use travic-ci encrypted tokens to push artefacts like wheels up to the rackspace CDN, and then pull them down again for testing. Can point you to relevant stuff if you are interested... Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Manylinux wheels for Cython
Hi, I don't know whether y'all have been following over at distutils-sig, but there's a new distutils PEP that defines a `manylinux` format for Linux wheels that work on many different x86 Linux distributions: https://www.python.org/dev/peps/pep-0513/ https://github.com/pypa/manylinux The latest version of pip will install these, if the client Linux system is compatible with the manylinux spec: https://pip.pypa.io/en/stable/news/ I've already built and used manylinux Cython wheels, which y'all are welcome to test with: pip install -f https://nipy.bic.berkeley.edu/manylinux cython (The wheels there don't have the right manylinux filenames yet, but they have the same contents as the ones that would go up to pypi). I've already had good use from these wheels in speeding up project builds into docker containers and virtualenvs, and I'd love to upload these to pypi. I have permissions on pypi to do this, but I wanted to check in with y'all first... Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Manylinux wheels for Cython
Hi, On Mon, Mar 7, 2016 at 5:47 PM, Matthew Brett wrote: > Hi, > > I don't know whether y'all have been following over at distutils-sig, > but there's a new distutils PEP that defines a `manylinux` format for > Linux wheels that work on many different x86 Linux distributions: > > https://www.python.org/dev/peps/pep-0513/ > https://github.com/pypa/manylinux > > The latest version of pip will install these, if the client Linux > system is compatible with the manylinux spec: > > https://pip.pypa.io/en/stable/news/ > > I've already built and used manylinux Cython wheels, which y'all are > welcome to test with: > > pip install -f https://nipy.bic.berkeley.edu/manylinux cython > > (The wheels there don't have the right manylinux filenames yet, but > they have the same contents as the ones that would go up to pypi). > > I've already had good use from these wheels in speeding up project > builds into docker containers and virtualenvs, and I'd love to upload > these to pypi. I have permissions on pypi to do this, but I wanted > to check in with y'all first... There is now a test wheel for Cython 0.23.4 and Python 3.5 on the testpypi server. This is me downloading and installing - a matter of a few seconds: $ python -m pip install -U pip Downloading/unpacking pip from https://pypi.python.org/packages/py2.py3/p/pip/pip-8.1.0-py2.py3-none-any.whl#md5=c6eca6736b2b8f7280fb25e44be7c51b Downloading pip-8.1.0-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded Installing collected packages: pip Found existing installation: pip 1.5.6 Uninstalling pip: Successfully uninstalled pip Successfully installed pip Cleaning up... $ pip install -i https://testpypi.python.org/pypi/ cython Collecting cython Using cached https://testpypi.python.org/packages/cp35/C/Cython/Cython-0.23.4-cp35-cp35m-manylinux1_x86_64.whl Installing collected packages: cython Successfully installed cython-0.23.4 $ cython --version Cython version 0.23.4 The installed Cython version compiles all the Demo *.pyx files OK. See also : https://mail.python.org/pipermail/wheel-builders/2016-March/50.html Best, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Manylinux wheels for Cython
Hi, On Tue, Mar 15, 2016 at 2:58 PM, Matthew Brett wrote: > Hi, > > On Mon, Mar 7, 2016 at 5:47 PM, Matthew Brett wrote: >> Hi, >> >> I don't know whether y'all have been following over at distutils-sig, >> but there's a new distutils PEP that defines a `manylinux` format for >> Linux wheels that work on many different x86 Linux distributions: >> >> https://www.python.org/dev/peps/pep-0513/ >> https://github.com/pypa/manylinux >> >> The latest version of pip will install these, if the client Linux >> system is compatible with the manylinux spec: >> >> https://pip.pypa.io/en/stable/news/ >> >> I've already built and used manylinux Cython wheels, which y'all are >> welcome to test with: >> >> pip install -f https://nipy.bic.berkeley.edu/manylinux cython >> >> (The wheels there don't have the right manylinux filenames yet, but >> they have the same contents as the ones that would go up to pypi). >> >> I've already had good use from these wheels in speeding up project >> builds into docker containers and virtualenvs, and I'd love to upload >> these to pypi. I have permissions on pypi to do this, but I wanted >> to check in with y'all first... > > There is now a test wheel for Cython 0.23.4 and Python 3.5 on the > testpypi server. > > This is me downloading and installing - a matter of a few seconds: > > $ python -m pip install -U pip > Downloading/unpacking pip from > https://pypi.python.org/packages/py2.py3/p/pip/pip-8.1.0-py2.py3-none-any.whl#md5=c6eca6736b2b8f7280fb25e44be7c51b > Downloading pip-8.1.0-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded > Installing collected packages: pip > Found existing installation: pip 1.5.6 > Uninstalling pip: > Successfully uninstalled pip > Successfully installed pip > Cleaning up... > $ pip install -i https://testpypi.python.org/pypi/ cython > Collecting cython > Using cached > https://testpypi.python.org/packages/cp35/C/Cython/Cython-0.23.4-cp35-cp35m-manylinux1_x86_64.whl > Installing collected packages: cython > Successfully installed cython-0.23.4 > $ cython --version > Cython version 0.23.4 > > The installed Cython version compiles all the Demo *.pyx files OK. > > See also : > https://mail.python.org/pipermail/wheel-builders/2016-March/50.html A manylinux wheel (gevent) is already the current most-downloaded binary wheel from pypi. A reminder that y'all can test the Cython wheels with: python -m pip install --upgrade pip # You need latest pip pip install -f https://nipy.bic.berkeley.edu/manylinux cython If I don't hear any objections, I plan to upload the Cython manylinux wheels on Monday 28th. Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Manylinux wheels for Cython
Hi, On Fri, Mar 25, 2016 at 11:46 AM, Matthew Brett wrote: > Hi, > > On Tue, Mar 15, 2016 at 2:58 PM, Matthew Brett > wrote: >> Hi, >> >> On Mon, Mar 7, 2016 at 5:47 PM, Matthew Brett >> wrote: >>> Hi, >>> >>> I don't know whether y'all have been following over at distutils-sig, >>> but there's a new distutils PEP that defines a `manylinux` format for >>> Linux wheels that work on many different x86 Linux distributions: >>> >>> https://www.python.org/dev/peps/pep-0513/ >>> https://github.com/pypa/manylinux >>> >>> The latest version of pip will install these, if the client Linux >>> system is compatible with the manylinux spec: >>> >>> https://pip.pypa.io/en/stable/news/ >>> >>> I've already built and used manylinux Cython wheels, which y'all are >>> welcome to test with: >>> >>> pip install -f https://nipy.bic.berkeley.edu/manylinux cython >>> >>> (The wheels there don't have the right manylinux filenames yet, but >>> they have the same contents as the ones that would go up to pypi). >>> >>> I've already had good use from these wheels in speeding up project >>> builds into docker containers and virtualenvs, and I'd love to upload >>> these to pypi. I have permissions on pypi to do this, but I wanted >>> to check in with y'all first... >> >> There is now a test wheel for Cython 0.23.4 and Python 3.5 on the >> testpypi server. >> >> This is me downloading and installing - a matter of a few seconds: >> >> $ python -m pip install -U pip >> Downloading/unpacking pip from >> https://pypi.python.org/packages/py2.py3/p/pip/pip-8.1.0-py2.py3-none-any.whl#md5=c6eca6736b2b8f7280fb25e44be7c51b >> Downloading pip-8.1.0-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded >> Installing collected packages: pip >> Found existing installation: pip 1.5.6 >> Uninstalling pip: >> Successfully uninstalled pip >> Successfully installed pip >> Cleaning up... >> $ pip install -i https://testpypi.python.org/pypi/ cython >> Collecting cython >> Using cached >> https://testpypi.python.org/packages/cp35/C/Cython/Cython-0.23.4-cp35-cp35m-manylinux1_x86_64.whl >> Installing collected packages: cython >> Successfully installed cython-0.23.4 >> $ cython --version >> Cython version 0.23.4 >> >> The installed Cython version compiles all the Demo *.pyx files OK. >> >> See also : >> https://mail.python.org/pipermail/wheel-builders/2016-March/50.html > > A manylinux wheel (gevent) is already the current most-downloaded > binary wheel from pypi. > > A reminder that y'all can test the Cython wheels with: > > python -m pip install --upgrade pip # You need latest pip > pip install -f https://nipy.bic.berkeley.edu/manylinux cython > > If I don't hear any objections, I plan to upload the Cython manylinux > wheels on Monday 28th. I uploaded manylinux wheels for Cython 0.23.5. If you're on Linux, and you upgrade pip to 8.1.1 (current) you should now get Cython via a manylinux wheel by default. Please do test and let me know of any problems. Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.23.5 released
On Wed, Mar 30, 2016 at 2:35 PM, Forest Gregg wrote: > Thanks! > > Are there also plans to post Windows wheels for cython 0.23.5 to pypi like > there was for 0.23.4? I did that earlier today, using an Appveyor build system : https://github.com/MacPython/cython-wheels/blob/master/appveyor.yml https://ci.appveyor.com/project/matthew-brett/cython-wheels http://win-wheels.scikit-image.org/ Do they work for you? Best, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cannot cythonize subclasses of setuptools.extension._Extension
On Thu, Apr 14, 2016 at 6:08 AM, Erik Bray wrote: > On Wed, Apr 13, 2016 at 9:35 PM, Manuel Nuno Melo > wrote: >> Hello devs, >> >> I'm developing the setup.py for a scientific package, MDAnalysis (see PR >> #799). We depend on distutils and setuptool. Namely, we use >> setuptools.extension.Extension class for our extensions. >> >> Some older versions of setuptools (<18.0) do filename cythonization >> themselves upon initialization of the Extension object. >> >> Because we want to control name cythonization ourselves I try to directly >> use distutils.extension.Extension, which has none of setuptools' >> cythonization. However, this doesn't work because setuptools patches >> distutils, so that distutils.extension.Extension effectively becomes >> setuptools.extension.Extension. > > I'm wondering what it is specifically you need to do in your > subclass--might it still be possible to do with a subclass of the > setuptools Extension? Not saying I disagree with the overall idea, > but I also wonder if there isn't a better way. I know this is a terrible and ugly hack, but the projects I work in have a 'fake_pyrex' directory, that fools setuptools into thinking that 'pyrex' is installed, and therefore prevents it from doing the .pyx -> .c filename conversions in the extension: https://github.com/regreg/regreg/blob/master/setup.py#L33 Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Manylinux wheels for Cython
Hi, On Mon, Mar 28, 2016 at 10:54 AM, Matthew Brett wrote: > Hi, > > On Fri, Mar 25, 2016 at 11:46 AM, Matthew Brett > wrote: >> Hi, >> >> On Tue, Mar 15, 2016 at 2:58 PM, Matthew Brett >> wrote: >>> Hi, >>> >>> On Mon, Mar 7, 2016 at 5:47 PM, Matthew Brett >>> wrote: >>>> Hi, >>>> >>>> I don't know whether y'all have been following over at distutils-sig, >>>> but there's a new distutils PEP that defines a `manylinux` format for >>>> Linux wheels that work on many different x86 Linux distributions: >>>> >>>> https://www.python.org/dev/peps/pep-0513/ >>>> https://github.com/pypa/manylinux >>>> >>>> The latest version of pip will install these, if the client Linux >>>> system is compatible with the manylinux spec: >>>> >>>> https://pip.pypa.io/en/stable/news/ >>>> >>>> I've already built and used manylinux Cython wheels, which y'all are >>>> welcome to test with: >>>> >>>> pip install -f https://nipy.bic.berkeley.edu/manylinux cython >>>> >>>> (The wheels there don't have the right manylinux filenames yet, but >>>> they have the same contents as the ones that would go up to pypi). >>>> >>>> I've already had good use from these wheels in speeding up project >>>> builds into docker containers and virtualenvs, and I'd love to upload >>>> these to pypi. I have permissions on pypi to do this, but I wanted >>>> to check in with y'all first... >>> >>> There is now a test wheel for Cython 0.23.4 and Python 3.5 on the >>> testpypi server. >>> >>> This is me downloading and installing - a matter of a few seconds: >>> >>> $ python -m pip install -U pip >>> Downloading/unpacking pip from >>> https://pypi.python.org/packages/py2.py3/p/pip/pip-8.1.0-py2.py3-none-any.whl#md5=c6eca6736b2b8f7280fb25e44be7c51b >>> Downloading pip-8.1.0-py2.py3-none-any.whl (1.2MB): 1.2MB downloaded >>> Installing collected packages: pip >>> Found existing installation: pip 1.5.6 >>> Uninstalling pip: >>> Successfully uninstalled pip >>> Successfully installed pip >>> Cleaning up... >>> $ pip install -i https://testpypi.python.org/pypi/ cython >>> Collecting cython >>> Using cached >>> https://testpypi.python.org/packages/cp35/C/Cython/Cython-0.23.4-cp35-cp35m-manylinux1_x86_64.whl >>> Installing collected packages: cython >>> Successfully installed cython-0.23.4 >>> $ cython --version >>> Cython version 0.23.4 >>> >>> The installed Cython version compiles all the Demo *.pyx files OK. >>> >>> See also : >>> https://mail.python.org/pipermail/wheel-builders/2016-March/50.html >> >> A manylinux wheel (gevent) is already the current most-downloaded >> binary wheel from pypi. >> >> A reminder that y'all can test the Cython wheels with: >> >> python -m pip install --upgrade pip # You need latest pip >> pip install -f https://nipy.bic.berkeley.edu/manylinux cython >> >> If I don't hear any objections, I plan to upload the Cython manylinux >> wheels on Monday 28th. > > I uploaded manylinux wheels for Cython 0.23.5. > > If you're on Linux, and you upgrade pip to 8.1.1 (current) you should > now get Cython via a manylinux wheel by default. > > Please do test and let me know of any problems. I haven't heard of any problems, and both current and historical numpy and scipy wheels appear to be working without problems as well. So, I propose to upload historical Cython wheels (for versions 0.17 and up) to speed up CI testing with older versions of Cython. You can test the built wheels now with something like: python -m pip install --upgrade pip pip install -f https://nipy.bic.berkeley.edu/manylinux cython==0.17 Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Manylinux wheels for Cython
On Fri, Apr 22, 2016 at 12:01 AM, Stefan Behnel wrote: > Matthew Brett schrieb am 21.04.2016 um 19:47: >> I haven't heard of any problems, and both current and historical numpy >> and scipy wheels appear to be working without problems as well. >> >> So, I propose to upload historical Cython wheels (for versions 0.17 >> and up) to speed up CI testing with older versions of Cython. > > There wasn't much feedback overall, so I'll just say that I'm happy you've > put some effort into this. Thanks! No problem, happy to return something for all the good use I get from Cython. > I'm all for uploading wheels for those older versions to reduce build times > for users. Even in the worst case, we can always take them out if anything > goes really wrong. OK - I uploaded 64-bit wheels back to Cython 0.17 - please let me know of any problems. I have built 32-bit wheels as well, but haven't uploaded them as yet. They are in https://nipy.bic.berkeley.edu/manylinux if y'all want to test. Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython 0.24.1 released
Hi, On Fri, Jul 15, 2016 at 9:32 AM, Stefan Behnel wrote: > Hi all! > > I just pushed a bug-fix-only release for the current 0.24 series. > The update should be safe for everyone using 0.24. > > https://pypi.python.org/pypi/Cython/0.24.1 > > Complete changelog follows below. > > SHA1 sum: > a837efb73c195585ce6e27cf53e3587285ccd39f Cython-0.24.1.tar.gz Thanks a lot for the release. I'm just building wheels via https://travis-ci.org/MacPython/cython-wheels - will upload soon. It would be good to get the wheels up before the source archive, if at all possible, to make sure that users don't get a blip where they don't have wheels for a while. Building should be straightforward, just a new commit to https://github.com/MacPython/cython-wheels with an edit to give the new tag name. If y'all agree that's a good idea, what's the best way to update the release procedure? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython 0.24.1 released
Hi, On Mon, Jul 18, 2016 at 4:56 PM, Robert Bradshaw wrote: > On Fri, Jul 15, 2016 at 4:22 AM, Matthew Brett > wrote: >> Hi, >> >> On Fri, Jul 15, 2016 at 9:32 AM, Stefan Behnel wrote: >>> Hi all! >>> >>> I just pushed a bug-fix-only release for the current 0.24 series. >>> The update should be safe for everyone using 0.24. >>> >>> https://pypi.python.org/pypi/Cython/0.24.1 >>> >>> Complete changelog follows below. >>> >>> SHA1 sum: >>> a837efb73c195585ce6e27cf53e3587285ccd39f Cython-0.24.1.tar.gz >> >> Thanks a lot for the release. >> >> I'm just building wheels via >> https://travis-ci.org/MacPython/cython-wheels - will upload soon. It >> would be good to get the wheels up before the source archive, if at >> all possible, to make sure that users don't get a blip where they >> don't have wheels for a while. Building should be straightforward, >> just a new commit to https://github.com/MacPython/cython-wheels with >> an edit to give the new tag name. If y'all agree that's a good idea, >> what's the best way to update the release procedure? > > Good point. > > I'm not sure the best process (for wheels on all platforms)--maybe an > email before we push to pypi once we've settled on what commit to > release? (Typically we have a thread of release candidates, etc.) Yes, that would certainly help. If whoever is releasing, wants to do the wheel building, the procedure is here: https://github.com/MacPython/cython-wheels#triggering-a-build (summary, edit appveyor and travis files to set tag, commit and push). But, if you shoot me an email, I'm happy to do it too, Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.25 alpha0
On Sat, Sep 24, 2016 at 10:12 PM, Robert Bradshaw wrote: > This prerelease version is also available at PyPi > > https://pypi.python.org/pypi/Cython/0.25a0 > > installable via > > pip install --pre cython It looks like the new BUILD file is breaking wheel builds on OSX and Windows: https://ci.appveyor.com/project/matthew-brett/cython-wheels/build/1.0.20/job/eu6n2eyc07a33ojl https://travis-ci.org/MacPython/cython-wheels/jobs/162527865#L235 Can it be renamed? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Re: Cython 0.25 alpha0
Hi, On Mon, Sep 26, 2016 at 1:42 AM, Alexey Buluy wrote: > > Who is this smart guy who decided to release this version into the open > without proper testing? > Now all packages in pip which use Cython are failing to install: > >> sudo pip install cassandra-driver==2.7.2 >> Downloading/unpacking cassandra-driver==2.7.2 >> Running setup.py egg_info for package cassandra-driver >> Unable to find pgen, not compiling formal grammar. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Plex/Scanners.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Plex/Actions.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Lexicon.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Scanning.py because >> it changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Parsing.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Visitor.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/FlowControl.py >> because it changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Code.py because it >> changed. >> Compiling >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Tempita/_tempita.py because it >> changed. >> [1/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Code.py >> [2/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/FlowControl.py >> [3/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Lexicon.py >> [4/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Parsing.py >> [5/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Scanning.py >> [6/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Compiler/Visitor.py >> [7/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Plex/Actions.py >> [8/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Plex/Scanners.py >> [9/9] Cythonizing >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Tempita/_tempita.py >> warning: no files found matching '*.pyx' under directory >> 'Cython/Debugger/Tests' >> warning: no files found matching '*.pxd' under directory >> 'Cython/Debugger/Tests' >> warning: no files found matching '*.h' under directory >> 'Cython/Debugger/Tests' >> warning: no files found matching '*.pxd' under directory >> 'Cython/Utility' >> gcc: error: >> /tmp/easy_install-AEclgi/Cython-0.25a0/Cython/Runtime/refnanny.c: No such >> file or directory >> gcc: fatal error: no input files >> compilation terminated. > > > Anybody knows how to fix this? That's odd - have you set up pip to fetch ``--pre`` packages by default somehow? When I do a pip install on my machine, I get the stable release. The pre-releases, like this one, are precisely to shake out problems before the stable releases. What do you get for a plain: pip install cython Best, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Preparations for Cython 0.26.1 and 0.27
Hi, On Thu, Aug 3, 2017 at 2:12 PM, Andy wrote: > One more thing: If there was a nightly wheel like for scipy and numpy, > we could run CI with Cython master. That might lead to finding issues > earlier. > We probably don't want to build cython from source on CI, as I expect that > would > take too much time. That's a good idea - I will set that up, and email back here with details. Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Preparations for Cython 0.26.1 and 0.27
Hi, On Thu, Aug 3, 2017 at 4:04 PM, Matthew Brett wrote: > Hi, > > On Thu, Aug 3, 2017 at 2:12 PM, Andy wrote: >> One more thing: If there was a nightly wheel like for scipy and numpy, >> we could run CI with Cython master. That might lead to finding issues >> earlier. >> We probably don't want to build cython from source on CI, as I expect that >> would >> take too much time. > > That's a good idea - I will set that up, and email back here with details. OK - I have set that up, wheels building on the "daily" branch here: https://travis-ci.org/MacPython/cython-wheels/branches But, I'm a bit worried by the pre-release naming scheme, because the built wheel has name of form "Cython-0.26.1a0-cp..." . Can I ask - where does the "1a0" come from? Can it be used to select the most recent pre-release wheel? I mean, if we build a wheel from a later commit, will pip find the later wheel before this one? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Preparations for Cython 0.26.1 and 0.27
Hi,
On Thu, Aug 3, 2017 at 2:39 PM, James C. McPherson
wrote:
> On 4/08/17 04:10 am, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Thu, Aug 3, 2017 at 4:04 PM, Matthew Brett
>> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Aug 3, 2017 at 2:12 PM, Andy wrote:
>>>>
>>>> One more thing: If there was a nightly wheel like for scipy and numpy,
>>>> we could run CI with Cython master. That might lead to finding issues
>>>> earlier.
>>>> We probably don't want to build cython from source on CI, as I expect
>>>> that
>>>> would
>>>> take too much time.
>>>
>>>
>>> That's a good idea - I will set that up, and email back here with
>>> details.
>>
>>
>> OK - I have set that up, wheels building on the "daily" branch here:
>>
>> https://travis-ci.org/MacPython/cython-wheels/branches
>>
>> But, I'm a bit worried by the pre-release naming scheme, because the
>> built wheel has name of form "Cython-0.26.1a0-cp..." . Can I ask -
>> where does the "1a0" come from? Can it be used to select the most
>> recent pre-release wheel? I mean, if we build a wheel from a later
>> commit, will pip find the later wheel before this one?
>
>
> I'm pretty sure that the '1a0' comes from changeset hash,
> to reflect however many changes this build has pulled in
> which are ahead of or behind trunk.
Sorry, I'm not quite sure what you mean by changeset hash - you mean a
hash of the output of "git diff 0.26..." or something? In which case,
the output would be useless for identifying the latest wheel, which
was my worry.
> Also, from reading
> https://travis-ci.org/MacPython/cython-wheels/jobs/255434019
> I'm not entirely sure that it's all setup correctly, given
> the prevalence of messages such as these:
>
>
>
> ERROR:root:code for hash blake2b was not found.
> Traceback (most recent call last):
> File "/opt/cp36m/lib/python3.6/hashlib.py", line 243, in
> globals()[__func_name] = __get_hash(__func_name)
> File "/opt/cp36m/lib/python3.6/hashlib.py", line 119, in
> __get_openssl_constructor
> return __get_builtin_constructor(name)
> File "/opt/cp36m/lib/python3.6/hashlib.py", line 113, in
> __get_builtin_constructor
> raise ValueError('unsupported hash type ' + name)
> ValueError: unsupported hash type blake2b
Those are benign, surprisingly ... It's a little bit difficult to
build Python 3.6 with that hash algorithm, but errors don't seem to
affect the wheel builds.
Cheers,
Matthew
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Preparations for Cython 0.26.1 and 0.27
On Thu, Aug 3, 2017 at 10:15 PM, Stefan Behnel wrote: > Am 3. August 2017 20:10:14 MESZ schrieb Matthew Brett: >>OK - I have set that up, wheels building on the "daily" branch here: >> >>https://travis-ci.org/MacPython/cython-wheels/branches > > Nice. > >>But, I'm a bit worried by the pre-release naming scheme, because the >>built wheel has name of form "Cython-0.26.1a0-cp..." . Can I ask - >>where does the "1a0" come from? Can it be used to select the most >>recent pre-release wheel? > > No, it's just the current version in Shadow.py, 0.26.1 alpha-0. It's > guaranteed to be increasing, but not for each build. > > >> I mean, if we build a wheel from a later >>commit, will pip find the later wheel before this one? > > There's probably a way to get at the current Travis build number. If you want > sequentially increasing version numbers, you could append that to the wheel > version. Or the current date, which would even be a human readable age > indicator. > OK - after some struggles, I'm adding the travis build number to the wheel name. You can test the daily wheels with: PRE_WHEELS="https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com"; pip install -f $PRE_WHEELS --pre cython Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
[Cython] Drop Cython wheels for 2.6?
Hi, The manylinux1 docker image has just stopped supporting Python 2.6, so we can no longer build Python 2.6 wheels without putting some hacks on top: https://github.com/pypa/manylinux/pull/125#issuecomment-345770870 Do y'all care about that? Cheers, Matthew ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
