On Fri, Dec 14, 2012 at 9:49 AM, Nathaniel Smith wrote:
> The top of the build log has the actual git command they used to check out
> the source - it's some clever GitHub thing that gives the same thing as
> pressing the green button would iirc. You could copy the commands from the
> log to check
The top of the build log has the actual git command they used to check out
the source - it's some clever GitHub thing that gives the same thing as
pressing the green button would iirc. You could copy the commands from the
log to check that out locally though and see what the .travis.tml actually
sa
On Fri, Dec 14, 2012 at 12:32 AM, Nathaniel Smith wrote:
> I only checked this build:
> https://secure.travis-ci.org/#!/certik/numpy/jobs/3656960
> But that log clearly shows 'python setup.py install' being used instead of
> 'pip install'. How certain are you that your branch actually has my fix?
I only checked this build:
https://secure.travis-ci.org/#!/certik/numpy/jobs/3656960
But that log clearly shows 'python setup.py install' being used instead of
'pip install'. How certain are you that your branch actually has my fix?
-n
On 14 Dec 2012 03:49, "Ondřej Čertík" wrote:
> On Thu, Dec 13
On Thu, Dec 13, 2012 at 7:16 PM, Charles R Harris
wrote:
>
>
> On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris
> wrote:
>>
>>
>>
>> On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík
>> wrote:
>>>
>>> Hi,
>>>
>>> Another weird bug sometimes happen in
>>> numpy/core/tests/test_iterator.py, it looks
On Thu, Dec 13, 2012 at 8:04 PM, Charles R Harris wrote:
>
>
> On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík wrote:
>
>> Hi,
>>
>> Another weird bug sometimes happen in
>> numpy/core/tests/test_iterator.py, it looks like this:
>>
>> ===
On Thu, Dec 13, 2012 at 7:23 PM, Ondřej Čertík wrote:
> Hi,
>
> Another weird bug sometimes happen in
> numpy/core/tests/test_iterator.py, it looks like this:
>
> ==
> FAIL: test_iterator.test_iter_array_cast
> ---
Hi,
Another weird bug sometimes happen in
numpy/core/tests/test_iterator.py, it looks like this:
==
FAIL: test_iterator.test_iter_array_cast
--
Traceback (most r
On Mon, Dec 5, 2011 at 12:39 PM, Mark Wiebe wrote:
> On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau wrote:
>>
>> On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
>> wrote:
>>
>> >
>> > We'll see how much interest there is. If it becomes official you may get
>> > more feedback on features. Ther
On 5 December 2011 17:57, mark florisson wrote:
> On 5 December 2011 17:48, Mark Wiebe wrote:
>> On Mon, Dec 5, 2011 at 9:37 AM, mark florisson
>> wrote:
>>>
>>> On 5 December 2011 17:25, Mark Wiebe wrote:
>>> > On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
>>> >>
>>> >>
>>> >>
>>>
On 5 December 2011 17:48, Mark Wiebe wrote:
> On Mon, Dec 5, 2011 at 9:37 AM, mark florisson
> wrote:
>>
>> On 5 December 2011 17:25, Mark Wiebe wrote:
>> > On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
>> >>
>> >>
>> >>
>> >>
>> >> Back to the bugs: here's a branch with all the chan
On Mon, Dec 5, 2011 at 9:37 AM, mark florisson wrote:
> On 5 December 2011 17:25, Mark Wiebe wrote:
> > On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
> >>
> >>
> >>
> >>
> >> Back to the bugs: here's a branch with all the changes I needed to get
> >> rational arithmetic to work:
> >>
On Mon, Dec 5, 2011 at 8:58 AM, David Cournapeau wrote:
> On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
> wrote:
>
> >
> > We'll see how much interest there is. If it becomes official you may get
> > more feedback on features. There are some advantages to having some user
> > types in numpy.
On 5 December 2011 17:25, Mark Wiebe wrote:
> On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
>>
>>
>>
>>
>> Back to the bugs: here's a branch with all the changes I needed to get
>> rational arithmetic to work:
>>
>> https://github.com/girving/numpy
>>
>> I discovered two more after
On Sun, Dec 4, 2011 at 11:37 PM, Geoffrey Irving wrote:
>
>
> Back to the bugs: here's a branch with all the changes I needed to get
> rational arithmetic to work:
>
>https://github.com/girving/numpy
>
> I discovered two more after the last email. One is another simple 0
> vs. 1 bug, and an
On Sun, Dec 4, 2011 at 9:45 PM, Charles R Harris
wrote:
>
> We'll see how much interest there is. If it becomes official you may get
> more feedback on features. There are some advantages to having some user
> types in numpy. One is that otherwise they tend to get lost, another is that
> having a
On Mon, Dec 5, 2011 at 6:59 AM, Charles R Harris
wrote:
> Hi Geoffrey,
>
> On Mon, Dec 5, 2011 at 12:37 AM, Geoffrey Irving wrote:
>>
>> On Sun, Dec 4, 2011 at 6:45 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving wrote:
>> >>
>> >> On Sun, Dec 4, 20
Hi Geoffrey,
On Mon, Dec 5, 2011 at 12:37 AM, Geoffrey Irving wrote:
> On Sun, Dec 4, 2011 at 6:45 PM, Charles R Harris
> wrote:
> >
> >
> > On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving wrote:
> >>
> >> On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > On Su
On Sun, Dec 4, 2011 at 6:45 PM, Charles R Harris
wrote:
>
>
> On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving wrote:
>>
>> On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving wrote:
>> >>
>> >> This may be the problem. Simpl
On Sun, Dec 4, 2011 at 6:59 PM, Geoffrey Irving wrote:
> On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
> wrote:
> >
> >
> > On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving wrote:
> >>
> >> This may be the problem. Simple diffs are pleasant. I'm guessing
> >> this code doesn't get a lot of
On Sun, Dec 4, 2011 at 5:18 PM, Charles R Harris
wrote:
>
>
> On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving wrote:
>>
>> This may be the problem. Simple diffs are pleasant. I'm guessing
>> this code doesn't get a lot of testing. Glad it's there, though!
>>
>> Geoffrey
>>
>> diff --git a/nump
On Sun, Dec 4, 2011 at 5:41 PM, Geoffrey Irving wrote:
> This may be the problem. Simple diffs are pleasant. I'm guessing
> this code doesn't get a lot of testing. Glad it's there, though!
>
> Geoffrey
>
> diff --git a/numpy/core/src/umath/ufunc_type_resolution.c
> b/numpy/core/src/umath/ufunc
This may be the problem. Simple diffs are pleasant. I'm guessing
this code doesn't get a lot of testing. Glad it's there, though!
Geoffrey
diff --git a/numpy/core/src/umath/ufunc_type_resolution.c
b/numpy/core/src/umath/ufunc_type_resolution.c
index 0d6cf19..a93eda1 100644
--- a/numpy/core/src
On Sat, Dec 3, 2011 at 8:14 PM, Geoffrey Irving wrote:
> Hello,
>
> I'm trying to add a fixed precision rational number dtype to numpy,
> and am running into an issue trying to register ufunc loops. The code
> in question looks like
>
>int npy_rational = PyArray_RegisterDataType(&rational_de
Hello,
I'm trying to add a fixed precision rational number dtype to numpy,
and am running into an issue trying to register ufunc loops. The code
in question looks like
int npy_rational = PyArray_RegisterDataType(&rational_descr);
PyObject* equal = ... // extract equal object from the imp
On 11/08/2011 12:14 PM, David Cournapeau wrote:
On Tue, Nov 8, 2011 at 9:20 AM, Mads Ipsen wrote:
Yup, that fixes it. For now, we can apply a temporary fix on our build
system. Is this something that'll go into, say, 1.6.2?
That's more of a workaround than a fix. We need to decide whether we
On Tue, Nov 8, 2011 at 9:20 AM, Mads Ipsen wrote:
> Yup, that fixes it. For now, we can apply a temporary fix on our build
> system. Is this something that'll go into, say, 1.6.2?
That's more of a workaround than a fix. We need to decide whether we
disable intrinsics altogether or wether we want
On 11/08/2011 10:01 AM, David Cournapeau wrote:
Hi Mads,
On Tue, Nov 8, 2011 at 8:40 AM, Mads Ipsen wrote:
Hi,
I am trying to build numpy-1.6.1 with the following gcc compiler specs:
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr -
On Tue, Nov 8, 2011 at 9:01 AM, David Cournapeau wrote:
> Hi Mads,
>
> On Tue, Nov 8, 2011 at 8:40 AM, Mads Ipsen wrote:
>> Hi,
>>
>> I am trying to build numpy-1.6.1 with the following gcc compiler specs:
>>
>> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
>> Configured with: .
Hi Mads,
On Tue, Nov 8, 2011 at 8:40 AM, Mads Ipsen wrote:
> Hi,
>
> I am trying to build numpy-1.6.1 with the following gcc compiler specs:
>
> Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/s
Hi,
I am trying to build numpy-1.6.1 with the following gcc compiler specs:
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --
hello --
i'm trying to build numpy-1.6.1. so far, it works on several machines
that i've tried, but now it's failing. I put some details on the
machine below. I tried to change the compiler, but setup.py objected
to the things I tried (--compiler=g++4, --compiler=icc).
thanks for any advice!
Amo
Wed, 16 Dec 2009 02:09:45 +, Chris wrote:
> Building a current checkout of scipy on OSX 10.6 fails when trying to
> compile scipy.special.lambertw, giving the message:
>
> Warning: No configuration returned, assuming unavailable.
>
> The full failure is here:
>
> http://img.skitch.com/20091
Building a current checkout of scipy on OSX 10.6 fails when trying
to compile scipy.special.lambertw, giving the message:
Warning: No configuration returned, assuming unavailable.
The full failure is here:
http://img.skitch.com/20091216-d4b8ueqh27g4fqwebu3e3wgfkq.jpg
On Wed, Nov 25, 2009 at 12:15 AM, wrote:
>
>
> I also ran the test of some old scipy against the trunk numpy:
>
> scipy.0.7.0('4826') finishes tests with some display errors
> scipy0.7.1rc3 test suite crashes
> both scipy versions build by David, according to __config__.py
I have build scipy 0
On Sun, Nov 22, 2009 at 1:40 PM, Charles R Harris
wrote:
>
>
> On Sun, Nov 22, 2009 at 6:28 AM, wrote:
>>
>> On Sun, Nov 22, 2009 at 2:35 AM, David Cournapeau
>> wrote:
>> > On Wed, Nov 18, 2009 at 6:10 PM, David Cournapeau
>> > wrote:
>> >> On Wed, Nov 18, 2009 at 12:38 AM, wrote:
>> >>
>> >
On Sun, Nov 22, 2009 at 6:28 AM, wrote:
> On Sun, Nov 22, 2009 at 2:35 AM, David Cournapeau
> wrote:
> > On Wed, Nov 18, 2009 at 6:10 PM, David Cournapeau
> wrote:
> >> On Wed, Nov 18, 2009 at 12:38 AM, wrote:
> >>
> >>>
> >>> Now numpy builds without problems.
> >>> When I run the tests I ge
On Sun, Nov 22, 2009 at 8:37 AM, wrote:
> On Sun, Nov 22, 2009 at 10:25 AM, David Cournapeau
> wrote:
> > On Mon, Nov 23, 2009 at 12:14 AM, wrote:
> >> On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau
> wrote:
> >>> On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
> >>> wrote:
>
> >
On Sun, Nov 22, 2009 at 10:47 AM, wrote:
> On Sun, Nov 22, 2009 at 10:37 AM, wrote:
>> On Sun, Nov 22, 2009 at 10:25 AM, David Cournapeau
>> wrote:
>>> On Mon, Nov 23, 2009 at 12:14 AM, wrote:
On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau
wrote:
> On Sun, Nov 22, 2009 a
On Sun, Nov 22, 2009 at 10:37 AM, wrote:
> On Sun, Nov 22, 2009 at 10:25 AM, David Cournapeau wrote:
>> On Mon, Nov 23, 2009 at 12:14 AM, wrote:
>>> On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau
>>> wrote:
On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
wrote:
>
>
On Sun, Nov 22, 2009 at 10:25 AM, David Cournapeau wrote:
> On Mon, Nov 23, 2009 at 12:14 AM, wrote:
>> On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau
>> wrote:
>>> On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
>>> wrote:
Might be nice to print out the actual values of np.s
On Mon, Nov 23, 2009 at 12:14 AM, wrote:
> On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau wrote:
>> On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
>> wrote:
>>>
>>> Might be nice to print out the actual values of np.spacing and np.nextafter
>>> here.
>>>
>>
>> Yes, I should add some uti
On Sun, Nov 22, 2009 at 10:01 AM, David Cournapeau wrote:
> On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
> wrote:
>>
>> Might be nice to print out the actual values of np.spacing and np.nextafter
>> here.
>>
>
> Yes, I should add some utilities to print those for this kind of test.
> But in
On Sun, Nov 22, 2009 at 11:45 PM, Charles R Harris
wrote:
>
> Might be nice to print out the actual values of np.spacing and np.nextafter
> here.
>
Yes, I should add some utilities to print those for this kind of test.
But in this case, I know the problem: mingw gcc use 80 bits long
double but it
On Sun, Nov 22, 2009 at 6:28 AM, wrote:
> On Sun, Nov 22, 2009 at 2:35 AM, David Cournapeau
> wrote:
> > On Wed, Nov 18, 2009 at 6:10 PM, David Cournapeau
> wrote:
> >> On Wed, Nov 18, 2009 at 12:38 AM, wrote:
> >>
> >>>
> >>> Now numpy builds without problems.
> >>> When I run the tests I ge
On Sun, Nov 22, 2009 at 2:35 AM, David Cournapeau wrote:
> On Wed, Nov 18, 2009 at 6:10 PM, David Cournapeau wrote:
>> On Wed, Nov 18, 2009 at 12:38 AM, wrote:
>>
>>>
>>> Now numpy builds without problems.
>>> When I run the tests I get 16 failures mostly nan related. I have no idea
>>> whether
On Wed, Nov 18, 2009 at 6:10 PM, David Cournapeau wrote:
> On Wed, Nov 18, 2009 at 12:38 AM, wrote:
>
>>
>> Now numpy builds without problems.
>> When I run the tests I get 16 failures mostly nan related. I have no idea
>> whether they are real or if there is still something screwed up in my
>>
Fri, 20 Nov 2009 10:55:35 +0900, David Cournapeau wrote:
> While checking everything builds for the 1.4.0 release, I noticed a
> problem with building the latex version:
>
> writing... done
> processing numpy-user.tex... user/index user/introduction
> user/whatisnumpy user/install user/howtofind u
Hi,
While checking everything builds for the 1.4.0 release, I noticed a
problem with building the latex version:
writing... done
processing numpy-user.tex... user/index user/introduction
user/whatisnumpy user/install user/howtofind user/basics
user/basics.types user/basics.creation user/basics.io
On Wed, Nov 18, 2009 at 12:38 AM, wrote:
>
> Now numpy builds without problems.
> When I run the tests I get 16 failures mostly nan related. I have no idea
> whether they are real or if there is still something screwed up in my
> setup. See below.
I can reproduce those. I did not see those beca
On Mon, Nov 16, 2009 at 10:52 PM, David Cournapeau wrote:
> On Tue, Nov 17, 2009 at 3:33 AM, wrote:
>
>>
>> Now, the numpy build runs for a while then breaks while building umath.
>>
>> Any ideas?
>
> The behavior of distutils with config files is mysterious, I gave up
> trying to understand it
On Tue, Nov 17, 2009 at 3:33 AM, wrote:
>
> Now, the numpy build runs for a while then breaks while building umath.
>
> Any ideas?
The behavior of distutils with config files is mysterious, I gave up
trying to understand it long ago :) I use scripts instead to control
everything from command li
On Mon, Nov 16, 2009 at 12:48 AM, David Cournapeau
wrote:
> josef.p...@gmail.com wrote:
>> Are there new changes to the configuration needed? mingw 3.4.5,
>> WindowsXP, Python 2.5.2
>>
>> Python.h is not picked up anymore:
>>
>> _configtest.c:1:20: Python.h: No such file or directory
>>
>> Josef
josef.p...@gmail.com wrote:
> Are there new changes to the configuration needed? mingw 3.4.5,
> WindowsXP, Python 2.5.2
>
> Python.h is not picked up anymore:
>
> _configtest.c:1:20: Python.h: No such file or directory
>
> Josef
>
> C:\Josef\_progs\Subversion\numpy-trunk>setup.py bdist
Could you
Are there new changes to the configuration needed? mingw 3.4.5,
WindowsXP, Python 2.5.2
Python.h is not picked up anymore:
_configtest.c:1:20: Python.h: No such file or directory
Josef
C:\Josef\_progs\Subversion\numpy-trunk>setup.py bdist
Running from numpy source directory.
F2PY Version 2_77
> This is the first report. I'll guess it is related to icc. What happens if
> you use gcc?
Indeed, with gcc4.1, the error isn't there.
Matthieu
--
Information System Engineer, Ph.D.
Website: http://matthieu-brucher.developpez.com/
Blogs: http://matt.eifelle.com and http://blog.developpez.com/?b
On Wed, May 27, 2009 at 7:51 AM, Matthieu Brucher <
matthieu.bruc...@gmail.com> wrote:
> Hi,
>
> I've just tested the latest numpy with my new configuration (Opteron
> 2220, 64bits with RH5.2, compiled with ICC 10.1.018) and I got this
> failure.
>
> ===
Hi,
I've just tested the latest numpy with my new configuration (Opteron
2220, 64bits with RH5.2, compiled with ICC 10.1.018) and I got this
failure.
==
FAIL: test_umath.TestLogAddExp2.test_logaddexp2_values
[...]
assert_almo
FWIW, I solved this just now by removing Sun Studio from
my PATH before build. It's clear that's a workaround
though and the build process failed to determine something
properly.
Jeff Blaine wrote:
>> What version of glibc do you have?
>
> None. Solaris does not use GNU libc.
>
> _
> What version of glibc do you have?
None. Solaris does not use GNU libc.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Mar 28, 2009 at 6:35 PM, Charles R Harris wrote:
>
>
> On Sat, Mar 28, 2009 at 5:31 PM, Jeff Blaine wrote:
>
>> Same problem with 1.3.0rc1
>>
>> Jeff Blaine wrote:
>> > Aside from this, the website for NumPy should have a link to the
>> > list subscription address, not a link to the list
On Sat, Mar 28, 2009 at 5:31 PM, Jeff Blaine wrote:
> Same problem with 1.3.0rc1
>
> Jeff Blaine wrote:
> > Aside from this, the website for NumPy should have a link to the
> > list subscription address, not a link to the list itself (which
> > cannot be posted to unless one is a member).
> >
> >
Same problem with 1.3.0rc1
Jeff Blaine wrote:
> Aside from this, the website for NumPy should have a link to the
> list subscription address, not a link to the list itself (which
> cannot be posted to unless one is a member).
>
> Python 2.4.2 (#2, Dec 6 2006, 17:18:19)
> [GCC 3.3.5] on sunos5
>
On Wed, Jan 21, 2009 at 10:53 AM, Gideon Simpson
wrote:
> ==
> FAIL: test_umath.TestComplexFunctions.test_against_cmath
> --
> Traceback (most recent call last):
Installing on a Sun machine with Red Hat linux, I got the following
error:
==
FAIL: test_umath.TestComplexFunctions.test_against_cmath
--
Traceback (most recent
On Sat, Jul 5, 2008 at 09:03, Gregor Thalhammer
<[EMAIL PROTECTED]> wrote:
> After upgrading to NumPy 1.1.0 (I installed
> numpy-1.1.0-win32-superpack-pyhon2.5) I observed a fatal failure with
> the following code which uses numpy.inner
>
> import numpy
> F = numpy.zeros(shape = (1,79), dtype = num
After upgrading to NumPy 1.1.0 (I installed
numpy-1.1.0-win32-superpack-pyhon2.5) I observed a fatal failure with
the following code which uses numpy.inner
import numpy
F = numpy.zeros(shape = (1,79), dtype = numpy.float64)
#this suceeds
FtF = numpy.inner(F,F.copy())
#this fails
FtF = numpy.inne
On Tue, Apr 29, 2008 at 04:43:09PM -0500, Glen W. Mabey wrote:
> Isn't that cool? I can only assume that it is a compiler bug and I will
> have to upgrade to a newer version of icc (I'm using 10.0.025, actually
> it's cce).
>
> After I do that, I'll post again if I have trouble.
Just to follow u
On Tue, Apr 29, 2008 at 01:01:55PM -0500, Charles R Harris wrote:
> Not really, it was just a shot in the dark. The thing is, if conv_python is
> being run on the same source each time, it should give the same result. So I
> suspect that something is changing the sources and that is what I'm tryi
On Tue, Apr 29, 2008 at 11:19 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 11:24:56AM -0500, Charles R Harris wrote:
> > Hmm, something must be mucking with the sources. You can run
> conv_template on the pure file from the src directory with
> >
> > python ../../distuti
On Tue, Apr 29, 2008 at 11:24:56AM -0500, Charles R Harris wrote:
> Hmm, something must be mucking with the sources. You can run conv_template on
> the pure file from the src directory with
>
> python ../../distutils/conv_template.py scalartypes.inc.src
>
> However, when called from within pyth
On Tue, Apr 29, 2008 at 9:50 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 10:41:25AM -0500, Charles R Harris wrote:
> > Could you post the new output? The conv_template routine has changed a
> bit, you should make sure you have the latest version. Also, it is pure
> pytho
On Tue, Apr 29, 2008 at 10:41:25AM -0500, Charles R Harris wrote:
> Could you post the new output? The conv_template routine has changed a bit,
> you should make sure you have the latest version. Also, it is pure python and
> the use of icc shouldn't make a difference in substituting the keys in
On Tue, Apr 29, 2008 at 9:21 AM, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> Robert,
>
Could you post the new output? The conv_template routine has changed a bit,
you should make sure you have the latest version. Also, it is pure python
and the use of icc shouldn't make a difference in substituti
Robert,
I do appreciate your response to this question (oh way back when) and am
just now getting back to this problem.
On Sat, Mar 01, 2008 at 02:17:46AM -0600, Robert Kern wrote:
> On Thu, Feb 28, 2008 at 1:21 PM, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > I'm using svn numpy
On Thu, Feb 28, 2008 at 1:21 PM, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm using svn numpy and get the following error upon executing
>
> /usr/local/bin/python2.5 setup.py config --noisy
> --cc=/opt/intel/cce/10.0.025/bin/icc --compiler=intel --fcompiler=intel
> build_clib buil
Hello,
I'm using svn numpy and get the following error upon executing
/usr/local/bin/python2.5 setup.py config --noisy
--cc=/opt/intel/cce/10.0.025/bin/icc --compiler=intel --fcompiler=intel
build_clib build_ext
I see:
conv_template:> build/src.linux-x86_64-2.5/numpy/core/src/scalartypes.in
77 matches
Mail list logo
