Re: [Numpy-discussion] example reading binary Fortran file
Neil Martinsen-Burrell wartburg.edu> writes:
>
> On 2009-05-29 10:12 , David Froger wrote:
> > I think the FortranFile class is not intended to read arrays written
> > with the syntax 'write(11) array1, array2, array3' (correct me if I'm
> > wrong). This is the use in the laboratory where I'm currently
> > completing a phd.
>
> You're half wrong. FortranFile can read arrays written as above, but it
> sees them as a single real array. So, with the attached Fortran program::
>
> In [1]: from fortranfile import FortranFile
>
> In [2]: f = FortranFile('uxuyp.bin', endian='<') # Original bug was
> incorrect byte order
>
> In [3]: u = f.readReals()
>
> In [4]: u.shape
> Out[4]: (20,)
>
> In [5]: u
> Out[5]:
> array([ 101., 111., 102., 112., 103., 113., 104., 114., 105.,
> 115., 201., 211., 202., 212., 203., 213., 204., 214.,
> 205., 215.], dtype=float32)
>
> In [6]: ux = u[:10].reshape(2,5); uy = u[10:].reshape(2,5)
>
> In [7]: p = f.readReals().reshape(2,5)
>
> In [8]: ux, uy, p
> Out[8]:
> (array([[ 101., 111., 102., 112., 103.],
> [ 113., 104., 114., 105., 115.]], dtype=float32),
> array([[ 201., 211., 202., 212., 203.],
> [ 213., 204., 214., 205., 215.]], dtype=float32),
> array([[ 301., 311., 302., 312., 303.],
> [ 313., 304., 314., 305., 315.]], dtype=float32))
>
> What doesn't currently work is to have arrays of mixed types in the same
> write statement, e.g.
>
> integer :: index(10)
> real :: x(10,10)
> ...
> write(13) x, index
>
> To address the original problem, I've changed the code to default to the
> native byte-ordering (f.ENDIAN='@') and to be more informative about
> what happened in the error. In the latest version (attached):
>
> In [1]: from fortranfile import FortranFile
>
> In [2]: f = FortranFile('uxuyp.bin', endian='>') # incorrect endian-ness
>
> In [3]: u = f.readReals()
>
> IOError: Could not read enough data. Wanted 1342177280 bytes, got 132
>
Hello,
I am trying to read a fortran unformatted binary file with
FortranFile as follows but I get an error.
-
>>> from FortranFile import FortranFile
>>> f = FortranFile("vor_465.float",endian="<")
>>> u = f.readReals()
Traceback (most recent call last):
File "", line 1, in
File "FortranFile.py", line 193, in readReals
data_str = self.readRecord()
File "FortranFile.py", line 140, in readRecord
data_str = self._read_exactly(l)
File "FortranFile.py", line 124, in _read_exactly
' Wanted %d bytes, got %d.' % (num_bytes, l))
IOError: Could not read enough data.
Wanted 1124054321 bytes, got 536870908.
--
My file, "vor_465.float" has the following size:
--
[pradeep@laptop ~]$ls -l vor_465.float
-rwxr-xr-x 1 pradeep staff 536870912 Feb 13 ***
-
I am sure this file has data in the right format as
when I read it using fortran using the following command:
--
open (in_file_id,FILE="vor_465.float",form='unformatted',
access='direct',recl=4*512*512*512)
read (in_file_id,rec=1) buffer
--
it works completely fine. This data contains single precision float
values for a scalar over a cube with 512 points in each direction.
Any ideas?
Pradeep
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to upload to pypi
David, On Tue, Feb 12, 2013 at 6:46 AM, David Cournapeau wrote: > On Tue, Feb 12, 2013 at 5:49 AM, Ondřej Čertík > wrote: >> Hi, >> >> I have uploaded the NumPy 1.7.0 source distribution to pypi: >> >> http://pypi.python.org/pypi/numpy/1.7.0 >> >> I did it by uploading the file PKG-INFO from numpy-1.7.0.tar.gz. It >> said "Error processing form. Form Failure; reset form submission" >> about 3x times, >> but on the 4th try it went through. I reported the issue here: >> >> https://sourceforge.net/tracker/?func=detail&aid=3604194&group_id=66150&atid=513504 >> >> I then attached the numpy-1.7.0.tar.gz and numpy-1.7.0.zip source files. >> >> Now I am having trouble attaching the windows installers, just like >> they are here: >> >> http://pypi.python.org/pypi/numpy/1.6.2 > > Those installers are ones built through bdist_wininst. You should > *not* upload superpack installers there, as most python tools will not > know what to do with it. For example, easy_install will not work with > those, even though it does with simple installers from bdist_wininst. > > So ideally, one should build simple (== bdist_wininst-generated) > installers using the lowest common denominator for architecture (i.e. > pure blas/lapack, not atlas), and the superpack installer on > sourceforge. Incidentally, that's why the super pack installer uses a > different filename, to avoid confusion. I see. I looked into my scripts and it turns out that actually I do build the bdist_wininst versions as well, I just didn't know what they are for, so I ignored them. Now I can see that those will get uploaded to pypi, so I did that now and it works! http://pypi.python.org/pypi/numpy/1.7.0 I learned something new today, thanks for the explanation. So pypi should be done. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to upload to pypi
Hi Robert, On Tue, Feb 12, 2013 at 2:40 AM, Robert Kern wrote: > On Tue, Feb 12, 2013 at 5:49 AM, Ondřej Čertík > wrote: >> Hi, >> >> I have uploaded the NumPy 1.7.0 source distribution to pypi: >> >> http://pypi.python.org/pypi/numpy/1.7.0 >> >> I did it by uploading the file PKG-INFO from numpy-1.7.0.tar.gz. It >> said "Error processing form. Form Failure; reset form submission" >> about 3x times, >> but on the 4th try it went through. I reported the issue here: >> >> https://sourceforge.net/tracker/?func=detail&aid=3604194&group_id=66150&atid=513504 >> >> I then attached the numpy-1.7.0.tar.gz and numpy-1.7.0.zip source files. >> >> Now I am having trouble attaching the windows installers, just like >> they are here: >> >> http://pypi.python.org/pypi/numpy/1.6.2 >> >> but whenever I upload the file >> numpy-1.7.0-win32-superpack-python2.5.exe (and set it as "MS Windows >> installer"), >> it uploads and then I get a blank page with the text: >> >> """ >> Error processing form >> >> invalid distribution file >> """ > > PyPI does some validation on the files that are uploaded. .exe files > must be created by bdist_wininst. > > https://bitbucket.org/loewis/pypi/src/fc588bcd668aba643e2e7f9bd6901a7a4296dddb/verify_filetype.py?at=default#cl-15 > > I am guessing that the superpack installer is manually built through > another mechanism. Ha, I see --- thanks for pointing me to the source code. All is clear now. > >> That's it Not very useful. Do you know if the sources of pypi are >> somewhere online? (I didn't find them, only a similar package >> https://github.com/schmir/pypiserver, but that doesn't seem to be it.) > > http://wiki.python.org/moin/CheeseShopDev > > You can get help with PyPI on Catalog-SIG: > > http://mail.python.org/mailman/listinfo/catalog-sig Thanks again. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] View on sliced array without copy
I did not know that. Thanks for the clear explanation.
Nicolas
On Feb 12, 2013, at 19:25 , Jaime Fernández del Río wrote:
> On Tue, Feb 12, 2013 at 9:53 AM, Nicolas Rougier
> wrote:
> Did I do something wrong or is it expected behavior ?
>
> Try:
>
> print (Z.view('f4'))[:50].base.base is Z # True
> print Z[:50].view('f4').base.base is Z # True
>
> This weird behaviour is fixed in the just-released numpy 1.7. From the notes
> of the release:
>
> The ``.base`` attribute on ndarrays, which is used on views to ensure that the
> underlying array owning the memory is not deallocated prematurely, now
> collapses out references when you have a view-of-a-view. For example::
>
> a = np.arange(10)
> b = a[1:]
> c = b[1:]
>
> In numpy 1.6, ``c.base`` is ``b``, and ``c.base.base`` is ``a``. In numpy 1.7,
> ``c.base`` is ``a``.
>
> Jaime
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de
> dominación mundial.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Help with python in C code
Hello all, I was able to successfully embed python code into C code. The basic skeleton is something like this : In C code : PyObject *pName, *pModule, *pFunc,*pArgs,*pReturn; PyArrayObject *cusForce; Py_Initialize(); import_array(); // required while using numpy arrays in C // Call some python code // Py_Decref all the used values Py_Finalize() Py_Finalize caused segmentation faults when numpy was one of import modules [node1:05762] Failing at address: 0x1 [node1:05762] [ 0] /lib64/libc.so.6 [0x3afa630280] [node1:05762] [ 1] /usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950aaf37] [node1:05762] [ 2] /usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950dd1d0] [node1:05762] [ 3] /usr/lib64/python2.4/site-packages/numpy/core/multiarray.so [0x2b4e950e22fa] [node1:05762] [ 4] /usr/lib64/libpython2.4.so.1.0(PyObject_IsTrue+0x37) [0x2b4e8a683c77] Which could be avoided by not calling Py_Finalize. But without calling Py_Finalize(), I am having huge memory leaks as the process keeps on increasing its memory usage as I see in top. Is there any clean way of calling Py_Finalize() when using numpy. Thanks santhosh ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.test('full') errors and failures
On Tue, Feb 12, 2013 at 1:28 PM, Daπid wrote: > On 12 February 2013 10:55, Dominic Steinitz wrote: > > Running unit tests for numpy > > NumPy version 1.8.0.dev-4600b2f > > I can see this is not the stable version, try the 1.7 that has been > just released. Sending the full output of this test run would be useful, even if 1.7.0 has no failures. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] View on sliced array without copy
On Tue, Feb 12, 2013 at 9:53 AM, Nicolas Rougier
wrote:
> Did I do something wrong or is it expected behavior ?
>
Try:
print (Z.view('f4'))[:50].base.base is Z # True
print Z[:50].view('f4').base.base is Z # True
This weird behaviour is fixed in the just-released numpy 1.7. From the
notes of the release:
The ``.base`` attribute on ndarrays, which is used on views to ensure that
the
underlying array owning the memory is not deallocated prematurely, now
collapses out references when you have a view-of-a-view. For example::
a = np.arange(10)
b = a[1:]
c = b[1:]
In numpy 1.6, ``c.base`` is ``b``, and ``c.base.base`` is ``a``. In numpy
1.7,
``c.base`` is ``a``.
Jaime
--
(\__/)
( O.o)
( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
de dominación mundial.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] View on sliced array without copy
Hi,
I'm trying to get a view on a sliced array without copy but I'm not able to do
it as illustrated below:
dtype = np.dtype( [('color', 'f4', 4)] )
Z = np.zeros(100, dtype=dtype)
print Z.view('f4').base is Z# True
print Z[:50].base is Z # True
print (Z.view('f4'))[:50].base is Z # False
print Z[:50].view('f4').base is Z # False
Did I do something wrong or is it expected behavior ?
Nicolas
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] number of tests
I should have added:
$ lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:Red Hat Enterprise Linux Server release 6.2 (Santiago)
Release:6.2
Codename: Santiago
$ python -c "import numpy; numpy.test('full')"
Running unit tests for numpy
NumPy version 1.6.2
NumPy is installed in
/opt/numpy/1.6.2/intel/13.0.1/lib/python2.7/site-packages/numpy
Python version 2.7.3 (default, Feb 9 2013, 16:14:16) [GCC 4.7.2]
nose version 1.2.1
So nobody knows why the number of tests run are different among
different runs of the same binary/library on different nodes?
https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt implies
they shouldn't...
Regards,
Davide Del Vento,
On 02/11/2013 08:54 PM, Davide Del Vento wrote:
> I compiled numpy 1.6.2 (right before 1.7 came out) with the intel
> compiler and MKL library. I'm trying to assess
> whether or not everything has been build fine. Since my machine is
> actually a cluster, I'm running the tests in different configurations
> (login node and batch script). However, I'm confused by the number of
> tests which ran.
> On the login nodes (either interactively or without tty) I get:
>
> Ran 3587 tests in 22.211s
> FAILED (KNOWNFAIL=5, SKIP=11, failures=2)
>
> Whereas in a remote batch node (with a script) I get:
>
> Ran 3229 tests in 15.642s
> OK (KNOWNFAIL=5, SKIP=19)
>
> Where did the 358 "missing" tests go in the batch run?
> The handful difference in SKIPped and FAILed (which I am
> investigating) cannot be the reason.
>
> What is it happening?
>
> PS: a similar thing happened with scipy, which I'm asking on the
> scipy mailing list.
>
> Thanks and Regards,
> Davide
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to upload to pypi
On Tue, Feb 12, 2013 at 5:49 AM, Ondřej Čertík wrote: > Hi, > > I have uploaded the NumPy 1.7.0 source distribution to pypi: > > http://pypi.python.org/pypi/numpy/1.7.0 > > I did it by uploading the file PKG-INFO from numpy-1.7.0.tar.gz. It > said "Error processing form. Form Failure; reset form submission" > about 3x times, > but on the 4th try it went through. I reported the issue here: > > https://sourceforge.net/tracker/?func=detail&aid=3604194&group_id=66150&atid=513504 > > I then attached the numpy-1.7.0.tar.gz and numpy-1.7.0.zip source files. > > Now I am having trouble attaching the windows installers, just like > they are here: > > http://pypi.python.org/pypi/numpy/1.6.2 Those installers are ones built through bdist_wininst. You should *not* upload superpack installers there, as most python tools will not know what to do with it. For example, easy_install will not work with those, even though it does with simple installers from bdist_wininst. So ideally, one should build simple (== bdist_wininst-generated) installers using the lowest common denominator for architecture (i.e. pure blas/lapack, not atlas), and the superpack installer on sourceforge. Incidentally, that's why the super pack installer uses a different filename, to avoid confusion. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] pip install numpy throwing a lot of output.
On 2/12/13 3:18 PM, Daπid wrote: > On 12 February 2013 14:58, Francesc Alted wrote: >> Yes, I think that's expected. Just to make sure, can you send some >> excerpts of the errors that you are getting? > Actually the errors are at the beginning of the process, so they are > out of the reach of my terminal right now. Seems like pip doesn't keep > a log in case of success. Well, I think these errors are part of the auto-discovering process of the functions supported by the libraries in the hosting OS (kind of `autoconf`for Python), so they can be considered 'normal'. > > The ones I can see are mostly warnings of unused variables and > functions, maybe this is the expected behaviour for a library? This > errors come from a complete reinstall instead of the original upgrade > (the cat closed the terminal, worst excuse ever!): [clip] These ones are not errors, but warnings. While it should be desirable to avoid any warning during the compilation process, not many libraries fulfill this (but patches for removing them are accepted). -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] pip install numpy throwing a lot of output.
On 12 February 2013 14:58, Francesc Alted wrote: > Yes, I think that's expected. Just to make sure, can you send some > excerpts of the errors that you are getting? Actually the errors are at the beginning of the process, so they are out of the reach of my terminal right now. Seems like pip doesn't keep a log in case of success. The ones I can see are mostly warnings of unused variables and functions, maybe this is the expected behaviour for a library? This errors come from a complete reinstall instead of the original upgrade (the cat closed the terminal, worst excuse ever!): compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/usr/include/python2.7 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.7/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/quicksort.c In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/quicksort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1170:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default] In file included from /usr/include/stdlib.h:24:0, from numpy/core/src/npysort/quicksort.c.src:31: /usr/include/features.h:168:0: note: this is the location of the previous definition In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/quicksort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1192:0: warning: "_XOPEN_SOURCE" redefined [enabled by default] In file included from /usr/include/stdlib.h:24:0, from numpy/core/src/npysort/quicksort.c.src:31: /usr/include/features.h:170:0: note: this is the location of the previous definition gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/mergesort.c In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/mergesort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1170:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default] In file included from /usr/include/stdlib.h:24:0, from numpy/core/src/npysort/mergesort.c.src:31: /usr/include/features.h:168:0: note: this is the location of the previous definition In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/mergesort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1192:0: warning: "_XOPEN_SOURCE" redefined [enabled by default] In file included from /usr/include/stdlib.h:24:0, from numpy/core/src/npysort/mergesort.c.src:31: /usr/include/features.h:170:0: note: this is the location of the previous definition gcc: build/src.linux-x86_64-2.7/numpy/core/src/npysort/heapsort.c In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/heapsort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1170:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default] In file included from /usr/include/stdlib.h:24:0, from numpy/core/src/npysort/heapsort.c.src:31: /usr/include/features.h:168:0: note: this is the location of the previous definition In file included from /usr/include/python2.7/pyconfig.h:6:0, from /usr/include/python2.7/Python.h:8, from numpy/core/src/private/npy_sort.h:5, from numpy/core/src/npysort/heapsort.c.src:32: /usr/include/python2.7/pyconfig-64.h:1192:0: warning: "_XOPEN_SOURCE" redefined [enabled by default] compile options: '-Ibuild/src.linux-x86_64-2.7/numpy/core/src/umath -Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/usr/include/python2.7 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.7/numpy/core/src/umath -c' gcc: numpy/core/src/umath/umathmodule_onefile.c In file included from numpy/core/
Re: [Numpy-discussion] pip install numpy throwing a lot of output.
On 2/12/13 1:37 PM, Daπid wrote: > I have just upgraded numpy with pip on Linux 64 bits with Python 2.7, > and I got *a lot* of output, so much it doesn't fit in the terminal. > Most of it are gcc commands, but there are many different errors > thrown by the compiler. Is this expected? Yes, I think that's expected. Just to make sure, can you send some excerpts of the errors that you are getting? > > I am not too worried as the test suite passes, but pip is supposed to > give only meaningful output (or at least, this is what the creators > intended). Well, pip needs to compile the libraries prior to install them, so compile messages are meaningful. Another question would be to reduce the amount of compile messages by default in NumPy, but I don't think this is realistic (and even not desirable). -- Francesc Alted ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] pip install numpy throwing a lot of output.
I have just upgraded numpy with pip on Linux 64 bits with Python 2.7, and I got *a lot* of output, so much it doesn't fit in the terminal. Most of it are gcc commands, but there are many different errors thrown by the compiler. Is this expected? I am not too worried as the test suite passes, but pip is supposed to give only meaningful output (or at least, this is what the creators intended). David. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] number of tests
On 12 February 2013 04:54, Davide Del Vento wrote:
> Ran 3587 tests in 22.211s
> FAILED (KNOWNFAIL=5, SKIP=11, failures=2)
>
> Whereas in a remote batch node (with a script) I get:
>
> Ran 3229 tests in 15.642s
> OK (KNOWNFAIL=5, SKIP=19)
On my machine (linux 64 bits)
In [3]: np.test('full')
Running unit tests for numpy
NumPy version 1.7.0
NumPy is installed in /usr/lib64/python2.7/site-packages/numpy
Python version 2.7.3 (default, Aug 9 2012, 17:23:57) [GCC 4.7.1
20120720 (Red Hat 4.7.1-5)]
nose version 1.2.1
--
Ran 4836 tests in 33.016s
OK (KNOWNFAIL=5, SKIP=1)
Out[3]:
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.test('full') errors and failures
On 12 February 2013 10:55, Dominic Steinitz wrote: > Running unit tests for numpy > NumPy version 1.8.0.dev-4600b2f I can see this is not the stable version, try the 1.7 that has been just released. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] How to upload to pypi
On Tue, Feb 12, 2013 at 5:49 AM, Ondřej Čertík wrote: > Hi, > > I have uploaded the NumPy 1.7.0 source distribution to pypi: > > http://pypi.python.org/pypi/numpy/1.7.0 > > I did it by uploading the file PKG-INFO from numpy-1.7.0.tar.gz. It > said "Error processing form. Form Failure; reset form submission" > about 3x times, > but on the 4th try it went through. I reported the issue here: > > https://sourceforge.net/tracker/?func=detail&aid=3604194&group_id=66150&atid=513504 > > I then attached the numpy-1.7.0.tar.gz and numpy-1.7.0.zip source files. > > Now I am having trouble attaching the windows installers, just like > they are here: > > http://pypi.python.org/pypi/numpy/1.6.2 > > but whenever I upload the file > numpy-1.7.0-win32-superpack-python2.5.exe (and set it as "MS Windows > installer"), > it uploads and then I get a blank page with the text: > > """ > Error processing form > > invalid distribution file > """ PyPI does some validation on the files that are uploaded. .exe files must be created by bdist_wininst. https://bitbucket.org/loewis/pypi/src/fc588bcd668aba643e2e7f9bd6901a7a4296dddb/verify_filetype.py?at=default#cl-15 I am guessing that the superpack installer is manually built through another mechanism. > That's it Not very useful. Do you know if the sources of pypi are > somewhere online? (I didn't find them, only a similar package > https://github.com/schmir/pypiserver, but that doesn't seem to be it.) http://wiki.python.org/moin/CheeseShopDev You can get help with PyPI on Catalog-SIG: http://mail.python.org/mailman/listinfo/catalog-sig -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.test('full') errors and failures
Apologies if this is the wrong mailing list.
I have installed bumpy using the excellent script here:
http://fonnesbeck.github.com/ScipySuperpack/
I ran numpy.test('full') and got several errors. Should I be worried?
Thanks, Dominic.
PS I can send the full errors if that would be helpful.
>>> np.test('full')
Running unit tests for numpy
NumPy version 1.8.0.dev-4600b2f
NumPy is installed in
/Library/Python/2.7/site-packages/numpy-1.8.0.dev_4600b2f_20130131-py2.7-macosx-10.8-intel.egg/numpy
Python version 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43) [GCC 4.2.1
(Apple Inc. build 5666) (dot 3)]
nose version 1.2.1
…
Ran 4471 tests in 13.065s
FAILED (KNOWNFAIL=5, SKIP=26, errors=2, failures=3)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
