Hi, I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy. cheers, David
On 12/22/2009 09:05 AM, David Cournapeau wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, This still crashes Python 2.7 with the test_multiarray.TestIO.test_ascii. The file numpy/core/src/multiarray/numpyos.c needs a change as per this thread: "test_multiarray.TestIO.test_ascii segmentation fault with Python2.7" http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047481.html The segmentation fault is avoided with this patch derived from the current numpy-1.4RC2 version and not the SVN version. Bruce
On Tue, Dec 22, 2009 at 8:50 AM, Bruce Southey <bsouthey@gmail.com> wrote:
On 12/22/2009 09:05 AM, David Cournapeau wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi, This still crashes Python 2.7 with the test_multiarray.TestIO.test_ascii.
The file numpy/core/src/multiarray/numpyos.c needs a change as per this thread: "test_multiarray.TestIO.test_ascii segmentation fault with Python2.7" http://mail.scipy.org/pipermail/numpy-discussion/2009-December/047481.html
The segmentation fault is avoided with this patch derived from the current numpy-1.4RC2 version and not the SVN version.
The patch looks ok, but the functions handle errors differently and I wonder if that has been completely audited. Chuck
ti, 2009-12-22 kello 10:16 -0700, Charles R Harris kirjoitti: [clip: PyOS_ascii_strtod -> PyOS_string_to_double]
The patch looks ok, but the functions handle errors differently and I wonder if that has been completely audited.
It can actually still crash from the same reason: PyOS_string_to_double docs say: """If no initial segment of the string is the valid representation of a floating-point number, set *endptr to point to the beginning of the string, raise ValueError, and return -1.0""" Indeed, $ gdb --args python3 -c "import numpy as np; np.fromstring('1,,', sep=',')" (gdb) run Program received signal SIGSEGV, Segmentation fault. PyErr_SetObject (exception=0x8291740, value=0xb7e926a0) at ../Python/errors.c:67 67 ../Python/errors.c: Tiedostoa tai hakemistoa ei ole. in ../Python/errors.c (gdb) bt #0 PyErr_SetObject (exception=0x8291740, value=0xb7e926a0) at ../Python/errors.c:67 #1 0x080e8d5a in PyErr_Format (exception=0x8291740, format=0x81a0998 "could not convert string to float: %.200s") at ../Python/errors.c:638 #2 0x080fb5fe in PyOS_string_to_double (s=0xb7ca2ae2 ",", endptr=0xbfffd130, overflow_exception=0x0) at ../Python/pystrtod.c:354 #3 0x004a9bfc in NumPyOS_ascii_strtod (s=0xb7ca2ae2 ",", endptr=0xbfffd130) at numpy/core/src/multiarray/numpyos.c:525 I suppose raising an exception requires ownership of GIL. So either we implement ASCII number parsing ourselves from scratch (or steal it from somewhere), or surround the call with appropriate GIL-acquiring wrappers plus if (PyErr_Occurred()) PyErr_Clear(); Anyway, how malformed input is handled is currently not so well specified anyway, so this part requires further fixes. -- Pauli Virtanen
On Tue, Dec 22, 2009 at 12:40 PM, Pauli Virtanen <pav@iki.fi> wrote:
ti, 2009-12-22 kello 10:16 -0700, Charles R Harris kirjoitti: [clip: PyOS_ascii_strtod -> PyOS_string_to_double]
The patch looks ok, but the functions handle errors differently and I wonder if that has been completely audited.
It can actually still crash from the same reason: PyOS_string_to_double docs say:
"""If no initial segment of the string is the valid representation of a floating-point number, set *endptr to point to the beginning of the string, raise ValueError, and return -1.0"""
Indeed,
$ gdb --args python3 -c "import numpy as np; np.fromstring('1,,', sep=',')" (gdb) run Program received signal SIGSEGV, Segmentation fault. PyErr_SetObject (exception=0x8291740, value=0xb7e926a0) at ../Python/errors.c:67 67 ../Python/errors.c: Tiedostoa tai hakemistoa ei ole. in ../Python/errors.c (gdb) bt #0 PyErr_SetObject (exception=0x8291740, value=0xb7e926a0) at ../Python/errors.c:67 #1 0x080e8d5a in PyErr_Format (exception=0x8291740, format=0x81a0998 "could not convert string to float: %.200s") at ../Python/errors.c:638 #2 0x080fb5fe in PyOS_string_to_double (s=0xb7ca2ae2 ",", endptr=0xbfffd130, overflow_exception=0x0) at ../Python/pystrtod.c:354 #3 0x004a9bfc in NumPyOS_ascii_strtod (s=0xb7ca2ae2 ",", endptr=0xbfffd130) at numpy/core/src/multiarray/numpyos.c:525
I suppose raising an exception requires ownership of GIL. So either we implement ASCII number parsing ourselves from scratch (or steal it from somewhere), or surround the call with appropriate GIL-acquiring wrappers plus if (PyErr_Occurred()) PyErr_Clear();
Could you expand a bit on this? There are several places where PyErr_Occurred are called and I am wondering if there is a problem. In fact, I moved one such check and a segfault went away, which made me suspicious... Chuck
ti, 2009-12-22 kello 14:32 -0700, Charles R Harris kirjoitti: [clip]
Could you expand a bit on this? There are several places where PyErr_Occurred are called and I am wondering if there is a problem. In fact, I moved one such check and a segfault went away, which made me suspicious...
I think here the point is that since PyOS_acii_strtod used to fail silently, also its replacement should -- so we'd need to clear any raised error before continuing. Pauli
On Tue, Dec 22, 2009 at 2:42 PM, Pauli Virtanen <pav@iki.fi> wrote:
ti, 2009-12-22 kello 14:32 -0700, Charles R Harris kirjoitti: [clip]
Could you expand a bit on this? There are several places where PyErr_Occurred are called and I am wondering if there is a problem. In fact, I moved one such check and a segfault went away, which made me suspicious...
I think here the point is that since PyOS_acii_strtod used to fail silently, also its replacement should -- so we'd need to clear any raised error before continuing.
But what about the GIL? That's what I'm curious about. Do we need to hold the GIL to check and clear and error? If so, there are other places where this will matter. I was under the impression that each thread had it's own error stack. But I don't know much about the GIL. Chuck
ti, 2009-12-22 kello 15:28 -0700, Charles R Harris kirjoitti: [clip]
But what about the GIL? That's what I'm curious about. Do we need to hold the GIL to check and clear and error? If so, there are other places where this will matter. I was under the impression that each thread had it's own error stack. But I don't know much about the GIL.
The issue seems to be that Py_BEGIN_ALLOW_THREADS / NPY_BEGIN_ALLOW_THREADS calls Python/ceval.c:PyEval_SaveThread(), which calls Python/pystate.c:PyThreadState_Swap, which sets the current thread state (Python/pystate.c:_PyThreadState_Current) to NULL. I'm not 100% sure if this is the same thing as releasing GIL, GIL is probably a subset of this. But, the exception information lives in the thread state -> NULL pointer dereference in PyErr_* -> BOOM. And yes, PyObject * PyErr_Occurred(void) { PyThreadState *tstate = PyThreadState_GET(); return tstate->curexc_type; } which probably means it shouldn't be called between ALLOW_THREADS. Needs to be wrapped between NPY_ALLOW_C_API & NPY_DISABLE_C_API, which call PyGILState_Ensure, which resurrects the thread state from some global dictionary or something. Pauli
On Wed, Dec 23, 2009 at 4:40 AM, Pauli Virtanen <pav@iki.fi> wrote:
I suppose raising an exception requires ownership of GIL.
I am curious: how did you know it was related to the GIL ? When I tried debugging the issue, I could not tell whereas this was a problem with python 2.7 or with numpy, and did not suspect the GIL at all. David
On Wed, Dec 23, 2009 at 12:50 AM, Bruce Southey <bsouthey@gmail.com> wrote:
This still crashes Python 2.7 with the test_multiarray.TestIO.test_ascii.
Could you file a ticket next time ? I could not follow closely the discussion the last week or so, and although I saw the crash, I missed it was discussed already. thanks, David
On 12/22/2009 09:53 PM, David Cournapeau wrote:
On Wed, Dec 23, 2009 at 12:50 AM, Bruce Southey<bsouthey@gmail.com> wrote:
This still crashes Python 2.7 with the test_multiarray.TestIO.test_ascii.
Could you file a ticket next time ? I could not follow closely the discussion the last week or so, and although I saw the crash, I missed it was discussed already.
thanks,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Sorry, Ticket 1345 http://projects.scipy.org/numpy/ticket/1345 I added patches for the 1.4 rc2 version and a patch for the SVN version. I only tested the 1.4 branch on Python 2.7 after you announced it because I follow the SVN. It was also somewhat confusing because a fix is was in the SVN version except that it needed to include Python 2.7. (This was due to the Python 3 support that was added since the 1.4 branch.) Some of the Python 3.1 features have been backported to Python 2.7 which will help with some of the porting to Python 3. For that reason, I would suggest that release notes indicate that Python 2.7 support is experimental - especially as Python 2.7 has only had one alpha release and the expected final release is 2010-06-26. Bruce
On Wed, Dec 23, 2009 at 11:54 PM, Bruce Southey <bsouthey@gmail.com> wrote:
Some of the Python 3.1 features have been backported to Python 2.7 which will help with some of the porting to Python 3. For that reason, I would suggest that release notes indicate that Python 2.7 support is experimental - especially as Python 2.7 has only had one alpha release and the expected final release is 2010-06-26.
I think I will not add this to the 1.4.x branch, then, because I don't understand the fix/what's broken very well. I suspect that people who want to try against python 2.7 can grab numpy from subversion and don't expect any released-quality code anyway. cheers, David
On Tue, Dec 22, 2009 at 9:05 AM, David Cournapeau <cournape@gmail.com>wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 132, in <module> import add_newdocs File "/home/gsever/Desktop/python-repo/numpy/numpy/add_newdocs.py", line 9, in <module> from lib import add_newdoc File "/home/gsever/Desktop/python-repo/numpy/numpy/lib/__init__.py", line 4, in <module> from type_check import * File "/home/gsever/Desktop/python-repo/numpy/numpy/lib/type_check.py",
This release results with the same import error on my system that I posted on http://old.nabble.com/Another-numpy-svn-installation-error-td26878029.html [gsever@ccn Desktop]$ python Python 2.6 (r26:66714, Jun 8 2009, 16:07:26) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. line 8, in <module> import numpy.core.numeric as _nx File "/home/gsever/Desktop/python-repo/numpy/numpy/core/__init__.py", line 6, in <module> import umath ImportError: /home/gsever/Desktop/python-repo/numpy/numpy/core/umath.so: undefined symbol: npy_spacing Is there any remedy for this error? -- Gökhan
On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Tue, Dec 22, 2009 at 9:05 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This release results with the same import error on my system that I posted on
Don't use develop, and install numpy normally, but from scratch. Develop mode has some quircks, and it does not worth it unless you want to work on numpy code yourself IMHO, cheers, David
On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau <cournape@gmail.com>wrote:
On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Tue, Dec 22, 2009 at 9:05 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This release results with the same import error on my system that I
posted
on
Don't use develop, and install numpy normally, but from scratch. Develop mode has some quircks, and it does not worth it unless you want to work on numpy code yourself IMHO,
OK, a clean svn check-out and python setup.py install I get another interesting import error: [gsever@ccn ~]$ pwd /home/gsever [gsever@ccn ~]$ python Python 2.6 (r26:66714, Jun 8 2009, 16:07:26) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 123, in <module> raise ImportError(msg) ImportError: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python intepreter from there.
I launch the interpreter from a different directory than where the sources located, however it still complains. For the develop, it is one of easiest ways to catch up the bug-fixes even though I don't work on the source directly. So far besides a few glitches it was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the directory on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs. I wonder how other people keep up the changes easily without using develop option.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
On Sat, Dec 26, 2009 at 2:19 PM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau <cournape@gmail.com>wrote:
On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Tue, Dec 22, 2009 at 9:05 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This release results with the same import error on my system that I
posted
on
Don't use develop, and install numpy normally, but from scratch. Develop mode has some quircks, and it does not worth it unless you want to work on numpy code yourself IMHO,
OK, a clean svn check-out and python setup.py install I get another interesting import error:
[gsever@ccn ~]$ pwd /home/gsever [gsever@ccn ~]$ python
Python 2.6 (r26:66714, Jun 8 2009, 16:07:26) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 123, in <module> raise ImportError(msg) ImportError: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python intepreter from there.
I launch the interpreter from a different directory than where the sources located, however it still complains.
For the develop, it is one of easiest ways to catch up the bug-fixes even though I don't work on the source directly. So far besides a few glitches it was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the directory on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs. I wonder how other people keep up the changes easily without using develop option.
I never see any of these problems and apparently no one else does either. There is something unique about your system. What does os.getcwd() return? Chuck
On Sat, Dec 26, 2009 at 4:15 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Sat, Dec 26, 2009 at 2:19 PM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau <cournape@gmail.com>wrote:
On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Tue, Dec 22, 2009 at 9:05 AM, David Cournapeau <cournape@gmail.com> wrote:
Hi,
I have just released the 2nd release candidate for numpy 1.4.0, which fixes a few critical bugs founds since the RC1. Tarballs and binary installers for numpy/scipy may be found on https://sourceforge.net/projects/numpy.
cheers,
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This release results with the same import error on my system that I
posted
on
Don't use develop, and install numpy normally, but from scratch. Develop mode has some quircks, and it does not worth it unless you want to work on numpy code yourself IMHO,
OK, a clean svn check-out and python setup.py install I get another interesting import error:
[gsever@ccn ~]$ pwd /home/gsever [gsever@ccn ~]$ python
Python 2.6 (r26:66714, Jun 8 2009, 16:07:26) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 123, in <module> raise ImportError(msg) ImportError: Error importing numpy: you should not try to import numpy from its source directory; please exit the numpy source tree, and relaunch your python intepreter from there.
I launch the interpreter from a different directory than where the sources located, however it still complains.
For the develop, it is one of easiest ways to catch up the bug-fixes even though I don't work on the source directly. So far besides a few glitches it was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the directory on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs. I wonder how other people keep up the changes easily without using develop option.
I never see any of these problems and apparently no one else does either. There is something unique about your system. What does os.getcwd() return?
Chuck
I removed numpy.egg-link (a remnant from setupegg.py develop) file under /usr/lib/python2.6/site-packages. Still I get the same error. Your query returns the same as pwd command:
import os os.getcwd() '/home/gsever/Desktop' exit() [gsever@ccn Desktop]$ pwd /home/gsever/Desktop
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
For the develop, it is one of easiest ways to catch up the bug-fixes even though I don't work on the source directly. So far besides a few glitches it was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the directory on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs.
If you do that, you have to be ready to look into the corresponding issues it brings.
I wonder how other people keep up the changes easily without using develop option.
I just install things, and avoid relying on too many developed versions of packages. David
On Sat, Dec 26, 2009 at 6:09 PM, David Cournapeau <cournape@gmail.com>wrote:
On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
For the develop, it is one of easiest ways to catch up the bug-fixes even though I don't work on the source directly. So far besides a few glitches
was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the
it directory
on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs.
If you do that, you have to be ready to look into the corresponding issues it brings.
I wonder how other people keep up the changes easily without using develop option.
I just install things, and avoid relying on too many developed versions of packages.
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fix comes following your suggestion. Use python install for the time being and remove the the check-out after installation. This prevents the funny import error even if I don't try to import the numpy from within I made the installation. -- Gökhan
On Mon, Dec 28, 2009 at 10:31 AM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Sat, Dec 26, 2009 at 6:09 PM, David Cournapeau <cournape@gmail.com>wrote:
On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
For the develop, it is one of easiest ways to catch up the bug-fixes
though I don't work on the source directly. So far besides a few glitches it was always working. I also install scipy, ipython, matplotlib, sympy and all other available packages using develop. Keep the checkouts in the
even directory
on my desktop and if/when necessary do svn up or whichever command it corresponds to their respective vcs.
If you do that, you have to be ready to look into the corresponding issues it brings.
I wonder how other people keep up the changes easily without using develop option.
I just install things, and avoid relying on too many developed versions of packages.
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Fix comes following your suggestion. Use python install for the time being and remove the the check-out after installation. This prevents the funny import error even if I don't try to import the numpy from within I made the installation.
-- Gökhan
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error. Could someone clarify this point? Is this due to API change in the numpy core? -- Gökhan
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error.
Please, please, always copy-and-paste the traceback when reporting an error. I know you aren't formally reporting a bug here, but it always helps.
Could someone clarify this point? Is this due to API change in the numpy core?
Cython/Pyrex code does a runtime check on the struct sizes of types. We have carefully added a member to the PyArrayDescr struct; i.e. it shouldn't cause any actual problems, but Cython does the check anyways. This affects a few modules in scipy, but shouldn't have affected anything in matplotlib. The traceback may help us identify the issue you are seeing. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error.
Please, please, always copy-and-paste the traceback when reporting an error. I know you aren't formally reporting a bug here, but it always helps.
Could someone clarify this point? Is this due to API change in the numpy core?
Cython/Pyrex code does a runtime check on the struct sizes of types. We have carefully added a member to the PyArrayDescr struct; i.e. it shouldn't cause any actual problems, but Cython does the check anyways. This affects a few modules in scipy, but shouldn't have affected anything in matplotlib. The traceback may help us identify the issue you are seeing.
It is too late for the tracebacks. I have already removed the problematic packages and did clean installs. However, next time I will be more careful while reporting such issues. If it helps, in both matplotlib (via ipython -pylab) and scipy.stats import cases the runtime errors was raised due to numpy.core.multiarray module import.
-- Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern <robert.kern@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error.
Please, please, always copy-and-paste the traceback when reporting an error. I know you aren't formally reporting a bug here, but it always helps.
Could someone clarify this point? Is this due to API change in the numpy core?
Cython/Pyrex code does a runtime check on the struct sizes of types. We have carefully added a member to the PyArrayDescr struct; i.e. it shouldn't cause any actual problems, but Cython does the check anyways. This affects a few modules in scipy, but shouldn't have affected anything in matplotlib. The traceback may help us identify the issue you are seeing.
It is too late for the tracebacks. I have already removed the problematic packages and did clean installs. However, next time I will be more careful while reporting such issues. If it helps, in both matplotlib (via ipython -pylab) and scipy.stats import cases the runtime errors was raised due to numpy.core.multiarray module import.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
Here is another interesting point to consider. To reproduce the runtime error I mentioned previously I downgraded numpy (from the latest check-out installation) following these steps: svn co http://svn.scipy.org/svn/numpy/branches/1.3.x/ numpy cd numpy python setup.py install Writing /usr/lib/python2.6/site-packages/numpy-1.3.1.dev8031-py2.6.egg-info I[2]: import matplotlib.pyplot as plt Segmentation fault I[3]: from scipy import stats Segmentation fault I have installed matplotlib and scipy using the latest numpy dev version. A little later I will downgrade matplotlib and scipy to their previous stable versions, and compile them using numpy 1.3.x. Afterwards I will update numpy and test to see if I can re-produce the runtime error to provide the tracebacks. First let me know if any tracebacks needed for these segfaults or are these known failures? ================================================================================ Platform : Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas Python : ('CPython', 'tags/r26', '66714') ================================================================================ -- Gökhan
On Mon, Dec 28, 2009 at 12:15 PM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern <robert.kern@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error.
Please, please, always copy-and-paste the traceback when reporting an error. I know you aren't formally reporting a bug here, but it always helps.
Could someone clarify this point? Is this due to API change in the numpy core?
Cython/Pyrex code does a runtime check on the struct sizes of types. We have carefully added a member to the PyArrayDescr struct; i.e. it shouldn't cause any actual problems, but Cython does the check anyways. This affects a few modules in scipy, but shouldn't have affected anything in matplotlib. The traceback may help us identify the issue you are seeing.
It is too late for the tracebacks. I have already removed the problematic packages and did clean installs. However, next time I will be more careful while reporting such issues. If it helps, in both matplotlib (via ipython -pylab) and scipy.stats import cases the runtime errors was raised due to numpy.core.multiarray module import.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
Here is another interesting point to consider. To reproduce the runtime error I mentioned previously I downgraded numpy (from the latest check-out installation) following these steps:
svn co http://svn.scipy.org/svn/numpy/branches/1.3.x/ numpy cd numpy python setup.py install Writing /usr/lib/python2.6/site-packages/numpy-1.3.1.dev8031-py2.6.egg-info
I[2]: import matplotlib.pyplot as plt Segmentation fault
I[3]: from scipy import stats Segmentation fault
I have installed matplotlib and scipy using the latest numpy dev version. A little later I will downgrade matplotlib and scipy to their previous stable versions, and compile them using numpy 1.3.x. Afterwards I will update numpy and test to see if I can re-produce the runtime error to provide the tracebacks. First let me know if any tracebacks needed for these segfaults or are these known failures?
================================================================================ Platform : Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas Python : ('CPython', 'tags/r26', '66714')
================================================================================
-- Gökhan
Since no one has replied, I tried to reproduce the runtime error but ended up with different errors. Read more for the details: svn co http://svn.scipy.org/svn/scipy/tags/0.7.1/ scipy python setup.py install Writing /usr/lib/python2.6/site-packages/scipy-0.7.1-py2.6.egg-info svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/tags/v0_99_0/matpl... python setup.py install Writing /usr/lib/python2.6/site-packages/matplotlib-0.99.0-py2.6.egg-info install them using
import numpy numpy.__version__ '1.3.1.dev8031'
scipy import is fine but matplotlib fails with a different import error. I wonder if the buildbots test the source and releases for against different numpy versions or it is just might system acting weird.
from scipy import stats
import matplotlib.pyplot as plt Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/pyplot.py", line 6, in <module> from matplotlib.figure import Figure, figaspect File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/figure.py", line 17, in <module> import artist File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/artist.py", line 5, in <module> from transforms import Bbox, IdentityTransform, TransformedBbox, TransformedPath File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/transforms.py", line 34, in <module> from matplotlib._path import affine_transform ImportError: No module named _path
Anyways, back to the main point. First remove the numpy 1.3.x: [root@ccn site-packages]# rm -rf numpy [root@ccn site-packages]# rm -rf numpy-1.3.1.dev8031-py2.6.egg-info and install from the latest trunk: svn co http://svn.scipy.org/svn/numpy/trunk numpy python setup.py install Writing /usr/lib/python2.6/site-packages/numpy-1.5.0.dev8032-py2.6.egg-info This time scipy asserts:
from scipy import stats Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py", line 7, in <module> from stats import * File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line 203, in <module> from morestats import find_repeats #is only reference to scipy.stats File "/usr/lib/python2.6/site-packages/scipy/stats/morestats.py", line 7, in <module> import distributions File "/usr/lib/python2.6/site-packages/scipy/stats/distributions.py", line 27, in <module> import vonmises_cython File "numpy.pxd", line 30, in scipy.stats.vonmises_cython (scipy/stats/vonmises_cython.c:2939) ValueError: numpy.dtype does not appear to be the correct type object
import matplotlib.pyplot as plt yields same as previous import attempt. I must have caught an old issue. -- Gökhan
On Mon, Dec 28, 2009 at 2:30 PM, Gökhan Sever <gokhansever@gmail.com> wrote:
On Mon, Dec 28, 2009 at 12:15 PM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever <gokhansever@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern <robert.kern@gmail.com>wrote:
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install. For instance I can't import some matplotlib and scipy modules without making a fresh installation for these packages. My attempts result with a runtime error.
Please, please, always copy-and-paste the traceback when reporting an error. I know you aren't formally reporting a bug here, but it always helps.
Could someone clarify this point? Is this due to API change in the numpy core?
Cython/Pyrex code does a runtime check on the struct sizes of types. We have carefully added a member to the PyArrayDescr struct; i.e. it shouldn't cause any actual problems, but Cython does the check anyways. This affects a few modules in scipy, but shouldn't have affected anything in matplotlib. The traceback may help us identify the issue you are seeing.
It is too late for the tracebacks. I have already removed the problematic packages and did clean installs. However, next time I will be more careful while reporting such issues. If it helps, in both matplotlib (via ipython -pylab) and scipy.stats import cases the runtime errors was raised due to numpy.core.multiarray module import.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
-- Gökhan
Here is another interesting point to consider. To reproduce the runtime error I mentioned previously I downgraded numpy (from the latest check-out installation) following these steps:
svn co http://svn.scipy.org/svn/numpy/branches/1.3.x/ numpy cd numpy python setup.py install Writing /usr/lib/python2.6/site-packages/numpy-1.3.1.dev8031-py2.6.egg-info
I[2]: import matplotlib.pyplot as plt Segmentation fault
I[3]: from scipy import stats Segmentation fault
I have installed matplotlib and scipy using the latest numpy dev version. A little later I will downgrade matplotlib and scipy to their previous stable versions, and compile them using numpy 1.3.x. Afterwards I will update numpy and test to see if I can re-produce the runtime error to provide the tracebacks. First let me know if any tracebacks needed for these segfaults or are these known failures?
================================================================================ Platform : Linux-2.6.29.6-217.2.3.fc11.i686.PAE-i686-with-fedora-11-Leonidas Python : ('CPython', 'tags/r26', '66714')
================================================================================
-- Gökhan
Since no one has replied, I tried to reproduce the runtime error but ended up with different errors. Read more for the details:
svn co http://svn.scipy.org/svn/scipy/tags/0.7.1/ scipy python setup.py install Writing /usr/lib/python2.6/site-packages/scipy-0.7.1-py2.6.egg-info
svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/tags/v0_99_0/matpl... python setup.py install Writing /usr/lib/python2.6/site-packages/matplotlib-0.99.0-py2.6.egg-info
install them using
import numpy numpy.__version__ '1.3.1.dev8031'
scipy import is fine but matplotlib fails with a different import error. I wonder if the buildbots test the source and releases for against different numpy versions or it is just might system acting weird.
from scipy import stats
import matplotlib.pyplot as plt Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/pyplot.py", line 6, in <module> from matplotlib.figure import Figure, figaspect File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/figure.py", line 17, in <module> import artist File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/artist.py", line 5, in <module> from transforms import Bbox, IdentityTransform, TransformedBbox, TransformedPath File "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/transforms.py", line 34, in <module> from matplotlib._path import affine_transform ImportError: No module named _path
Anyways, back to the main point. First remove the numpy 1.3.x:
[root@ccn site-packages]# rm -rf numpy [root@ccn site-packages]# rm -rf numpy-1.3.1.dev8031-py2.6.egg-info
and install from the latest trunk:
svn co http://svn.scipy.org/svn/numpy/trunk numpy python setup.py install Writing /usr/lib/python2.6/site-packages/numpy-1.5.0.dev8032-py2.6.egg-info
This time scipy asserts:
from scipy import stats
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.6/site-packages/scipy/stats/__init__.py", line 7, in <module> from stats import * File "/usr/lib/python2.6/site-packages/scipy/stats/stats.py", line 203, in <module> from morestats import find_repeats #is only reference to scipy.stats File "/usr/lib/python2.6/site-packages/scipy/stats/morestats.py", line 7, in <module> import distributions File "/usr/lib/python2.6/site-packages/scipy/stats/distributions.py", line 27, in <module> import vonmises_cython File "numpy.pxd", line 30, in scipy.stats.vonmises_cython (scipy/stats/vonmises_cython.c:2939) ValueError: numpy.dtype does not appear to be the correct type object
That is the cython problem. I think they fixed it, but I don't know if that is in the recent release. Chuck
On Tue, Dec 29, 2009 at 2:00 AM, Gökhan Sever <gokhansever@gmail.com> wrote:
One interesting thing I have noticed while installing the numpy from the source is that numpy dependent libraries must be re-installed and this must be a clean re-install.
This is expected if you build libraries against dev versions of numpy - we simply cannot guarantee that every revision in the trunk will be ABI compatible. David
participants (6)
-
Bruce Southey -
Charles R Harris -
David Cournapeau -
Gökhan Sever -
Pauli Virtanen -
Robert Kern