On Fri, Apr 22, 2016 at 11:27 AM, Olivier Grisel
wrote:
> 2016-04-22 20:17 GMT+02:00 Matthew Brett :
>>
>> The github releases idea sounds intriguing. Do you have any
>> experience with that? Are there good examples other than the API
>> documentation?
>>
>> https://developer.github.com/v3/repo
2016-04-22 20:17 GMT+02:00 Matthew Brett :
>
> The github releases idea sounds intriguing. Do you have any
> experience with that? Are there good examples other than the API
> documentation?
>
> https://developer.github.com/v3/repos/releases/
I never used it by I assume we could create a numpy-
On Thu, Apr 21, 2016 at 1:47 AM, Olivier Grisel
wrote:
> 2016-04-20 16:57 GMT+02:00 Matthew Brett :
>> On Wed, Apr 20, 2016 at 1:59 AM, Olivier Grisel
>> wrote:
>>> Thanks,
>>>
>>> I think next we could upgrade the travis configuration of numpy and
>>> scipy to build and upload manylinux1 wheels
2016-04-20 16:57 GMT+02:00 Matthew Brett :
> On Wed, Apr 20, 2016 at 1:59 AM, Olivier Grisel
> wrote:
>> Thanks,
>>
>> I think next we could upgrade the travis configuration of numpy and
>> scipy to build and upload manylinux1 wheels to
>> http://travis-dev-wheels.scipy.org/ for downstream project
Hi,
On Wed, Apr 20, 2016 at 3:33 AM, Jens Nielsen wrote:
> Thanks
>
> I can confirm that the new narrow unicode build wheels of Scipy works as
> expected for my project.
> @Oliver Grisel Thanks for finding the Travis issue it's probably worth
> considering switching the Travis build to 2.7.11 to
On Wed, Apr 20, 2016 at 1:59 AM, Olivier Grisel
wrote:
> Thanks,
>
> I think next we could upgrade the travis configuration of numpy and
> scipy to build and upload manylinux1 wheels to
> http://travis-dev-wheels.scipy.org/ for downstream project to test
> against the master branch of numpy and sc
Thanks
I can confirm that the new narrow unicode build wheels of Scipy works as
expected for my project.
@Oliver Grisel Thanks for finding the Travis issue it's probably worth
considering switching the Travis build to 2.7.11 to avoid other similar
issues.
The old versions of numpy are very handy
Thanks,
I think next we could upgrade the travis configuration of numpy and
scipy to build and upload manylinux1 wheels to
http://travis-dev-wheels.scipy.org/ for downstream project to test
against the master branch of numpy and scipy whithout having to build
those from source.
However that would
On Tue, Apr 19, 2016 at 1:12 AM, Olivier Grisel
wrote:
> I think that would be very useful, e.g. for downstream projects to
> check that they work properly with old versions using a simple pip
> install command on their CI workers.
Done for numpy 1.6.0 through 1.10.4, scipy 0.9 through scipy 0.16
I think that would be very useful, e.g. for downstream projects to
check that they work properly with old versions using a simple pip
install command on their CI workers.
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://ma
Hi,
On Mon, Apr 18, 2016 at 2:49 PM, Matthew Brett wrote:
> On Sun, Apr 17, 2016 at 9:48 AM, Jens Nielsen wrote:
>> I have tested the new cp27m wheels and they seem to work great.
>>
>> @Matthew I am using the:
>>
>> ```
>> sudo: required
>> dist: trusty
>>
>> images mentioned here https://docs.
On Sun, Apr 17, 2016 at 9:48 AM, Jens Nielsen wrote:
> I have tested the new cp27m wheels and they seem to work great.
>
> @Matthew I am using the:
>
> ```
> sudo: required
> dist: trusty
>
> images mentioned here https://docs.travis-ci.com/user/ci-environment/. As
> far as I can see you are doing
On Apr 17, 2016 10:47 AM, "Olivier Grisel" wrote:
>
> Thanks for the clarification, I read your original report too quickly.
>
> I wonder why the travis maintainers built Python 2.7 with a
> non-standard unicode option.
Because for some reason cpython's configure script (in the now somewhat
ancie
Yeah! That's the bug I encountered! So, that would explain why this seems
to work fine now (I tried it out a bit on Friday on a CentOS6 system, but
didn't run the test suite).
Cheers!
Ben Root
On Sun, Apr 17, 2016 at 1:46 PM, Olivier Grisel
wrote:
> Thanks for the clarification, I read your ori
Thanks for the clarification, I read your original report too quickly.
I wonder why the travis maintainers built Python 2.7 with a
non-standard unicode option.
Edit (after googling): this is a known issue. The image with Python
2.7.11 will be fixed:
https://github.com/travis-ci/travis-ci/issues/
I have tested the new cp27m wheels and they seem to work great.
@Matthew I am using the:
```
sudo: required
dist: trusty
images mentioned here https://docs.travis-ci.com/user/ci-environment/. As
far as I can see you are doing:
sudo: false
dist: trusty
I had no idea such an image exist since it'
I tried on trusty and is also picked
numpy-1.11.0-cp27-cp27mu-manylinux1_x86_64.whl using the system python
2.7 (in a virtualenv with pip 8.1.1):
>>> import pip
>>> pip.pep425tags.get_abi_tag()
'cp27mu'
Outside of the virtualenv I still have the pip version from ubuntu
trusty and it does cannot d
On Sat, Apr 16, 2016 at 8:02 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 14, 2016 at 11:04 AM, Matthew Brett
> wrote:
>> Hi,
>>
>> On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote:
>>> I have tried testing the wheels in a project that runs tests on Travis's
>>> Trusty infrastructure which
Hi,
On Thu, Apr 14, 2016 at 11:04 AM, Matthew Brett wrote:
> Hi,
>
> On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote:
>> I have tried testing the wheels in a project that runs tests on Travis's
>> Trusty infrastructure which. The wheels work great for python 3.5 and saves
>> us several minut
On Thu, Apr 14, 2016 at 1:22 PM, Matthew Brett wrote:
> On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote:
>> I have tried testing the wheels in a project that runs tests on Travis's
>> Trusty infrastructure which. The wheels work great for python 3.5 and saves
>> us several minuts of runtime.
On Thu, Apr 14, 2016 at 1:47 PM, Jonathan Helmus wrote:
>
>
> On 4/14/16 3:11 PM, Matthew Brett wrote:
>>
>> On Thu, Apr 14, 2016 at 12:57 PM, Matthew Brett
>> wrote:
>>>
>>> On Thu, Apr 14, 2016 at 12:25 PM, Jonathan Helmus
>>> wrote:
On 4/14/16 1:26 PM, Matthew Brett wrote:
On 4/14/16 3:11 PM, Matthew Brett wrote:
On Thu, Apr 14, 2016 at 12:57 PM, Matthew Brett wrote:
On Thu, Apr 14, 2016 at 12:25 PM, Jonathan Helmus wrote:
On 4/14/16 1:26 PM, Matthew Brett wrote:
Hi,
On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root
wrote:
Are we going to have to have docu
On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote:
> I have tried testing the wheels in a project that runs tests on Travis's
> Trusty infrastructure which. The wheels work great for python 3.5 and saves
> us several minuts of runtime.
>
> However, I am having trouble using the wheels on python
On Thu, Apr 14, 2016 at 12:57 PM, Matthew Brett wrote:
> On Thu, Apr 14, 2016 at 12:25 PM, Jonathan Helmus wrote:
>>
>>
>> On 4/14/16 1:26 PM, Matthew Brett wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root
>>> wrote:
Are we going to have to have documentation
I am honestly surprised that these worked (I haven't gotten around to
testing for myself). I could have sworn there was a difference in how
Continuum compiled python such that any binaries built against a stock
python would not work in a conda environment. I ran into issues a couple
years ago where
On Thu, Apr 14, 2016 at 12:07 PM, Nathaniel Smith wrote:
> On Apr 14, 2016 11:11 AM, "Benjamin Root" wrote:
> >
> > Are we going to have to have documentation somewhere making it clear
> that the numpy wheel shouldn't be used in a conda environment? Not that I
> would expect this issue to come u
On Thu, Apr 14, 2016 at 12:25 PM, Jonathan Helmus wrote:
>
>
> On 4/14/16 1:26 PM, Matthew Brett wrote:
>>
>> Hi,
>>
>> On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root
>> wrote:
>>>
>>> Are we going to have to have documentation somewhere making it clear that
>>> the numpy wheel shouldn't be used
On 4/14/16 1:26 PM, Matthew Brett wrote:
Hi,
On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root wrote:
Are we going to have to have documentation somewhere making it clear that
the numpy wheel shouldn't be used in a conda environment? Not that I would
expect this issue to come up all that often
On Apr 14, 2016 11:11 AM, "Benjamin Root" wrote:
>
> Are we going to have to have documentation somewhere making it clear that
the numpy wheel shouldn't be used in a conda environment? Not that I would
expect this issue to come up all that often, but I could imagine a scenario
where a non-scientis
Actually, conda pip will install the wheels that you put up. The good news
is: they all (by which I mean *numpy* and *scipy* both on 2.7 and 3.5) pass!
On Thu, Apr 14, 2016 at 7:26 PM, Matthew Brett
wrote:
> Hi,
>
> On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root
> wrote:
> > Are we going to h
Hi,
On Thu, Apr 14, 2016 at 11:11 AM, Benjamin Root wrote:
> Are we going to have to have documentation somewhere making it clear that
> the numpy wheel shouldn't be used in a conda environment? Not that I would
> expect this issue to come up all that often, but I could imagine a scenario
> where
Are we going to have to have documentation somewhere making it clear that
the numpy wheel shouldn't be used in a conda environment? Not that I would
expect this issue to come up all that often, but I could imagine a scenario
where a non-scientist is simply using a base conda distribution because
th
Hi,
On Thu, Apr 14, 2016 at 8:02 AM, Jens Nielsen wrote:
> I have tried testing the wheels in a project that runs tests on Travis's
> Trusty infrastructure which. The wheels work great for python 3.5 and saves
> us several minuts of runtime.
>
> However, I am having trouble using the wheels on py
I have tried testing the wheels in a project that runs tests on Travis's
Trusty infrastructure which. The wheels work great for python 3.5 and saves
us several minuts of runtime.
However, I am having trouble using the wheels on python 2.7 on the same
Trusty machines. It seems to be because the whe
https://github.com/numpy/numpy/issues/7545
On Wed, Apr 13, 2016 at 3:38 PM, Nathaniel Smith wrote:
> I can reproduce in self-compiled 1.9, so it's not a new bug.
>
> I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF,
> where our special sigint handler is getting left in place ev
I can reproduce in self-compiled 1.9, so it's not a new bug.
I think something's going wrong with NPY_SIGINT_ON / NPY_SIGINT_OFF,
where our special sigint handler is getting left in place even after
our code finishes running.
Skimming the code, my best guess is that this is due to a race
conditio
On 13 Apr 2016 21:48, "Matthew Brett" wrote:
>
> On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
> wrote:
> > On 13 April 2016 at 20:15, Matthew Brett
wrote:
> >> Done. If y'all are on linux, and you have pip >= 8.11, you should
> >> now see this kind of thing:
> >
> > That's fantastic. Thanks
On Wed, Apr 13, 2016 at 1:15 PM, Matthew Brett
wrote:
> On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett
> wrote:
> > Hi,
> >
> > On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett
> wrote:
> >> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock
> wrote:
> >>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGi
On Wed, Apr 13, 2016 at 1:29 PM, Oscar Benjamin
wrote:
> On 13 April 2016 at 20:15, Matthew Brett wrote:
>> Done. If y'all are on linux, and you have pip >= 8.11, you should
>> now see this kind of thing:
>
> That's fantastic. Thanks Matt!
>
> I just test installed this and ran numpy.test(). Al
On 13 April 2016 at 20:15, Matthew Brett wrote:
> Done. If y'all are on linux, and you have pip >= 8.11, you should
> now see this kind of thing:
That's fantastic. Thanks Matt!
I just test installed this and ran numpy.test(). All tests passed but
then I got a segfault at the end by (semi-accid
Woot! \o/
On Wed, Apr 13, 2016 at 12:15 PM, Matthew Brett
wrote:
> On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett
> wrote:
> > Hi,
> >
> > On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett
> wrote:
> >> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock
> wrote:
> >>> On Fri, Mar 25, 2016 at 3:02 AM, Ro
\o/
Thank you very much Matthew. I will upload the scikit-learn wheels soon.
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Apr 12, 2016 at 7:15 PM, Matthew Brett wrote:
> Hi,
>
> On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett wrote:
>> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock
>> wrote:
>>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
>>> wrote:
I suspect that many of the maintainers of major
Hi,
On Sat, Apr 2, 2016 at 6:11 PM, Matthew Brett wrote:
> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock wrote:
>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
>> wrote:
>>> I suspect that many of the maintainers of major scipy-ecosystem projects are
>>> aware of these (or other similar)
Matthew, you are correct. A lot of things happened with random integer
generation recently (including deprecating random_integers), but I believe
those warnings should be squashed in the up and coming version of SciPy
from what I remember.
On Mon, Apr 4, 2016 at 6:47 PM, Matthew Brett
wrote:
>
Hi,
On Mon, Apr 4, 2016 at 9:02 AM, Peter Cock wrote:
> On Sun, Apr 3, 2016 at 2:11 AM, Matthew Brett wrote:
>> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock
>> wrote:
>>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
>>> wrote:
I suspect that many of the maintainers of major scipy-
On Sun, Apr 3, 2016 at 2:11 AM, Matthew Brett wrote:
> On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock wrote:
>> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
>> wrote:
>>> I suspect that many of the maintainers of major scipy-ecosystem projects are
>>> aware of these (or other similar) travi
I ran some tests on an image of the future ubuntu xenial that ships a
version of pip recent enough to install manylinux1 wheels by default
and everything looks fine.
Just to clarify, those wheels use openblas 0.2.17 that have proven to
be both fast and very stable on various CPU architectures whil
typo:
python -m install --upgrade pip
should read:
python -m pip install --upgrade pip
--
Olivier
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Mar 25, 2016 at 6:39 AM, Peter Cock wrote:
> On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon
> wrote:
>> I suspect that many of the maintainers of major scipy-ecosystem projects are
>> aware of these (or other similar) travis wheel caches, but would guess that
>> the pool of travis-c
On Fri, Mar 25, 2016 at 3:02 AM, Robert T. McGibbon wrote:
> I suspect that many of the maintainers of major scipy-ecosystem projects are
> aware of these (or other similar) travis wheel caches, but would guess that
> the pool of travis-ci python users who weren't aware of these wheel caches
> is
I suspect that many of the maintainers of major scipy-ecosystem projects
are aware of these (or other similar) travis wheel caches, but would guess
that the pool of travis-ci python users who weren't aware of these wheel
caches is much much larger. So there will still be a lot of travis-ci clock
cy
On Thu, Mar 24, 2016 at 11:44 AM, Peter Cock wrote:
> On Thu, Mar 24, 2016 at 6:37 PM, Nathaniel Smith wrote:
>> On Mar 24, 2016 8:04 AM, "Peter Cock" wrote:
>>>
>>> Hi Nathaniel,
>>>
>>> Will you be providing portable Linux wheels aka manylinux1?
>>> https://www.python.org/dev/peps/pep-0513/
>>
On Thu, Mar 24, 2016 at 6:37 PM, Nathaniel Smith wrote:
> On Mar 24, 2016 8:04 AM, "Peter Cock" wrote:
>>
>> Hi Nathaniel,
>>
>> Will you be providing portable Linux wheels aka manylinux1?
>> https://www.python.org/dev/peps/pep-0513/
>
> Matthew Brett will (probably) do the actual work, but yeah,
On Mar 24, 2016 8:04 AM, "Peter Cock" wrote:
>
> Hi Nathaniel,
>
> Will you be providing portable Linux wheels aka manylinux1?
> https://www.python.org/dev/peps/pep-0513/
Matthew Brett will (probably) do the actual work, but yeah, that's the idea
exactly. Note the author list on that PEP ;-)
-n
On Thu, Mar 24, 2016 at 4:04 PM, Peter Cock
wrote:
> Hi Nathaniel,
>
> Will you be providing portable Linux wheels aka manylinux1?
> https://www.python.org/dev/peps/pep-0513/
>
> Does this also open up the door to releasing wheels for SciPy
> too?
>
That should work just fine.
> While speeding
Hi Nathaniel,
Will you be providing portable Linux wheels aka manylinux1?
https://www.python.org/dev/peps/pep-0513/
Does this also open up the door to releasing wheels for SciPy
too?
While speeding up "pip install" would be of benefit in itself,
I am particularly keen to see this for use within
On Tue, Mar 15, 2016 at 7:10 PM, Nathaniel Smith wrote:
> On Mar 15, 2016 5:54 PM, "Charles R Harris"
> wrote:
> >
> >
> >
> > On Tue, Mar 15, 2016 at 5:33 PM, Nathaniel Smith wrote:
> >>
> >> Hi all,
> >>
> >> Just a heads-up that we're planning to upload Linux wheels for numpy
> >> to PyPI so
On Mar 15, 2016 5:54 PM, "Charles R Harris"
wrote:
>
>
>
> On Tue, Mar 15, 2016 at 5:33 PM, Nathaniel Smith wrote:
>>
>> Hi all,
>>
>> Just a heads-up that we're planning to upload Linux wheels for numpy
>> to PyPI soon. Unless there's some objection, these will be using
>> ATLAS, just like the c
On Tue, Mar 15, 2016 at 5:33 PM, Nathaniel Smith wrote:
> Hi all,
>
> Just a heads-up that we're planning to upload Linux wheels for numpy
> to PyPI soon. Unless there's some objection, these will be using
> ATLAS, just like the current Windows wheels, for the same reasons --
> moving to somethin
Hi all,
Just a heads-up that we're planning to upload Linux wheels for numpy
to PyPI soon. Unless there's some objection, these will be using
ATLAS, just like the current Windows wheels, for the same reasons --
moving to something faster like OpenBLAS would be good, but given the
concerns about Op
61 matches
Mail list logo
