Pauli Virtanen wrote:
Thu, 23 Apr 2009 14:54:10 -0400, Chris Colbert wrote:
[clip]
libatlas-sse2-dev
[clip]
The pastebin links to site.cfg build.log and test.log are at the end of
this email. If anyone could help me out here as to what the problems may
be, i would appreciate it!
The
charlie wrote:
Hi All,
Hi Charlie,
I got the undefined symbol: PyUnicodeUCS2_FromUnicode error when
importing numpy.
I have my own non-root version of python 2.5.4 final installed with
--prefix=$HOME/usr.
PYTHONHOME=$HOME/usr;
David Cournapeau wrote:
Michael Abshoff wrote:
David Cournapeau wrote:
Hi David,
With Sage we do the cythonization in parallel and for now build
extension serially, but we have code to do that in parallel, too. Given
that we are building 180 extensions or so the speedup is linear. I often
David Cournapeau wrote:
Michael Abshoff wrote:
Hi David,
Sure, it also works for incremental builds and I do that many, many
times a day, i.e. for each patch I merge into the Sage library. What
gets recompiled is decided by our own dependency tracking code which we
want to push
Sturla Molden wrote:
On 2/12/2009 12:20 PM, David Cournapeau wrote:
Hi,
It does if you have access to the parallel toolbox I mentioned earlier
in this thread (again, no experience with it, but I think it is
specially popular on clusters; in that case, though, it is not limited
to
David Cournapeau wrote:
Matthieu Brucher wrote:
For BLAS level 3, the MKL is parallelized (so matrix multiplication is).
Hi David,
Same for ATLAS: thread support is one focus in the 3.9 serie, currently
in development.
ATLAS has had thread support for a long, long time. The 3.9 series
David Cournapeau wrote:
Hoyt Koepke wrote:
SNIP
Actually, I would advise using only 3.8.2. Previous versions had bugs
for some core routines used by numpy (at least 3.8.0 did). I am a bit
surprised that a 64 bits-built atlas would be runnable at all in a 32
bits binary - I would expect the
Gael Varoquaux wrote:
Hi Gael,
OK, here we go for the stupid questions showing that I really don't
understaind building well:
I am building numpy on a Mandriva x86_64. I built an optimized ATLAS, and
added the relevant lines to the site.cfg so that numpy does find the
libraries. But now I
George wrote:
David Cournapeau cournape at gmail.com writes:
SNIP
Hi George,
I have debugged some more but I am in deep (murky) waters, but I have also ran
out of ideas. If anybody has some more suggestions, please post them.
Could you post a full example with additional version info that
Gong, Shawn (Contractor) wrote:
hi list,
Hi Shawn,
I tried to build numpy 1.2.1 on Solaris 9 with gcc 3.4.6
when I typed “python setup.py build”, I got error from hashlib.py
File /home/sgong/dev181/dist/lib/python2.5/hashlib.py, line 133, in
module
md5 =
Travis E. Oliphant wrote:
Hello,
SNIP
Hi Travis,
It is currently available as a single-click installer for Windows XP
(x86), Mac OS X (a universal binary for OS X 10.4 and above), and
RedHat 3 and 4 (x86 and amd64).
I am sure you mean RHEL 3 and 4? This Redhat 3 and 4 always strikes me
as
igor Halperin wrote:
Hi,
Hi
I get numpy errors after I install Picalo (www.picalo.org
http://www.picalo.org) on Mac OS X 10.4.11 Tiger. I have tried to
import numpy in Picalo using the instructions in PicaloCookBook, p.101.
I get this error message which I don't understand.
Per Picalo
David Cournapeau wrote:
On Thu, Nov 27, 2008 at 1:16 AM, Peter Norton
[EMAIL PROTECTED] wrote:
On Tue, Nov 25, 2008 at 11:28 PM, David Cournapeau
[EMAIL PROTECTED] wrote:
Charles R Harris wrote:
What happens if you go the usual python setup.py {build,install} route?
Won't go far since it
David Cournapeau wrote:
On Fri, Nov 14, 2008 at 5:23 AM, frank wang [EMAIL PROTECTED] wrote:
Hi,
Hi,
Can you provide a working example to build Numpy with MKL in window and
linux?
The reason I am thinking to build the system is that I need to make the
speed match with matlab.
The MKL
David Cournapeau wrote:
On Fri, Nov 14, 2008 at 11:07 AM, Michael Abshoff
[EMAIL PROTECTED] wrote:
David Cournapeau wrote:
On Fri, Nov 14, 2008 at 5:23 AM, frank wang [EMAIL PROTECTED] wrote:
Hi,
Hi,
Can you provide a working example to build Numpy with MKL in window and
linux
David Warde-Farley wrote:
Hello folks,
Hi David,
I'm doing some rather big matrix products on a G5, and ran into this.
Strangely on the same OS version on my Intel laptop, this isn't an
issue. Available memory isn't the problem either, I don't think, this
machine is pretty beefy.
Can
Gideon Simpson wrote:
Not sure if this is an issue with numpy or an issue with fink python
2.6, but when trying to build numpy, I get the following error:
Unfortunately numpy 1.2.x does not support Python 2.6. IIRC support is
planned for numpy 1.3.
gcc -L/sw/lib -bundle
Jarrod Millman wrote:
On Sat, Nov 1, 2008 at 1:07 AM, Robert Kern [EMAIL PROTECTED] wrote:
Hi,
On Fri, Oct 31, 2008 at 05:25, David Cournapeau
[EMAIL PROTECTED] wrote:
I was wondering whether it was really worth having a lot of magic
going on in fcompilers for flags like -msse2 and co
David Cournapeau wrote:
Michael Abshoff wrote:
Hi David,
Sure, but there isn't even a 32 bit gcc out there that can produce 64
bit PE binaries (aside from the MinGW fork that AFAIK does not work
particularly well and allegedly has issues with the cleanliness of some
of the code which
David Cournapeau wrote:
Ravi wrote:
Hi,
Michael Abshoff already responded to the ATLAS question. I don't have access
to a 64-bit Windows. Given the volume of legacy 32-bit applications where I
work, there is no chance of 64-bit Windows access for me for at least 2
years.
Windows 64
David Cournapeau wrote:
Hi David,
I started a wiki page on the issues related to windows, 64 bits and
python 2.6 (those issues are somewhat related at some level):
http://scipy.org/scipy/numpy/wiki/MicrosoftToolchainSupport
Cool.
If you want to help, you can try solving one problem. In
David Cournapeau wrote:
Hi David,
Michael Abshoff wrote:
Well, I think that having a 64 bit native build of numpy/scipy using an
efficient and non-commercial licensed BLAS/Lapack (i.e. not Intel MKL)
can't be a bad thing :)
Yes, of course. But it is useful to be able to use a 32 bits
David Cournapeau wrote:
Michael Abshoff wrote:
Hi David,
Sorry for not being precise: Both python and numpy have been build with
OPT=-DNDEBUG -g -O0 -fwrapv -Wall -Wstrict-prototypes
Hm, strange. I don't know why you can't get any debug info, then.
well, it looks like some sort of stack
David Cournapeau wrote:
Michael Abshoff wrote:
Hi David,
This is python 2.5.2 build with gcc 4.2.4, numpy itself is build with
-O0, i.e. this is unlikely to be a compiler bug IMHO. This bug has
been present in 1.0.4, 1.1.0 and it seems unfixed in 1.2.rc1. The numpy
1.1 test suite passed
Robert Kern wrote:
On Fri, Aug 22, 2008 at 07:00, Chris Kees
[EMAIL PROTECTED] wrote:
Hi,
I've been experimenting with both a non-framework, non-universal 64-bit
build and a 4-way universal build of the python (2.6) trunk with numpy
1.1.1. The non-framework 64 build appears to give me
Hi,
I have been playing with 64 bit numpy/scipy on OSX 10.5 Intel again. I
thought everything worked after the last time we discussed this, but I
noticed that I had Scipy import failures in for example optimize since
the gfortran I used creates 32 bit code per default.
So I build a gcc 4.2.4
Stéfan van der Walt wrote:
2008/8/21 Michael Abshoff [EMAIL PROTECTED]:
William Stein is at Scipy 08 and there seems to be at least some
interest in 64 bit OSX binaries. If anyone wants one let me know and I
can put one together once Scipy 0.7 and Numpy 1.1.2 are out.
There is still
Stéfan van der Walt wrote:
2008/6/24 Stéfan van der Walt [EMAIL PROTECTED]:
It should be fairly easy to execute the example code, just to make
sure it runs. We can always work out a scheme to test its validity
later.
Hi,
Mike Hansen just explained to me that the Sage doctest system sets
Fernando Perez wrote:
On Mon, Jun 23, 2008 at 4:58 PM, Michael Abshoff
[EMAIL PROTECTED] wrote:
Hi Fernando,
a) Random variables
we have some small extensions to the doctesting framework that allow us
to mark doctests as #random so that the result it not checked. Carl
Witty wrote some code
Charles R Harris wrote:
On Mon, Jun 23, 2008 at 5:58 PM, Michael Abshoff
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Stéfan van der Walt wrote:
2008/6/24 Stéfan van der Walt [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
It should be fairly easy to execute
Dan Yamins wrote:
Hi Dan,
./configure --disable-toolbox-glue
--prefix=/Users/mabshoff/64bitnumpy/python-2.5.2-bin --with-gcc=gcc
-m64
Let's build numpy 1.1.0:
bsd:64bitnumpy mabshoff$ tar xf numpy-1.1.0.tar.gz
bsd:64bitnumpy mabshoff$ cd numpy-1.1.0
bsd:numpy-1.1.0
Charles R Harris wrote:
On Fri, Jun 6, 2008 at 3:50 PM, Dan Yamins [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I'm forced to run it as su. (Is this a bad idea?)
Anyhow, when I
do run sudo python setup.py install in the numpy-1.1.0
Dan Yamins wrote:
Hello folks,
I did port Sage and hence Python with numpy and scipy to 64 bit OSX and
below are some sample build instructions for just building python and
numpy in 64 bit mode.
Try
In [3]: numpy.dtype(numpy.uintp).itemsize
Out[3]: 4
which is the size
Stéfan van der Walt wrote:
2008/5/20 Charles R Harris [EMAIL PROTECTED]:
On Tue, May 20, 2008 at 9:48 AM, Jarrod Millman [EMAIL PROTECTED]
wrote:
On Tue, May 20, 2008 at 8:37 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Two of the buildbots are showing problems, probably
Charles R Harris wrote:
Hi Chuck,
Curious bug on Stefan's Ubuntu build client:
ImportError: /usr/lib/atlas/libblas.so.3gf: undefined symbol:
_gfortran_st_write_done
make[1]: *** [test] Error 1
Anyone know what that is about?
You need to link -lgfortran since the blas you use was compiled
35 matches
Mail list logo
