Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Tue, Dec 29, 2009 at 2:00 AM, Gökhan Sever 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 2:30 PM, Gökhan Sever wrote:
>
>
> On Mon, Dec 28, 2009 at 12:15 PM, Gökhan Sever wrote:
>
>>
>>
>> On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever wrote:
>>
>>>
>>>
>>> On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern wrote:
>>>
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever
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/matplotlib
> 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 "", line 1, in
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/pyplot.py", line
> 6, in
> from matplotlib.figure import Figure, figaspect
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/figure.py", line
> 17, in
> import artist
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/artist.py", line
> 5, in
> from transforms import Bbox, IdentityTransform, TransformedBbox,
> TransformedPath
> File
> "/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/transforms.py",
> line 34, in
> from matplotlib._path import aff
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 12:15 PM, Gökhan Sever wrote:
>
>
> On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever wrote:
>
>>
>>
>> On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern wrote:
>>
>>> On Mon, Dec 28, 2009 at 11:00, Gökhan Sever
>>> 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/matplotlib
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 "", line 1, in
File
"/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/pyplot.py", line
6, in
from matplotlib.figure import Figure, figaspect
File
"/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/figure.py", line
17, in
import artist
File
"/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/artist.py", line
5, in
from transforms import Bbox, IdentityTransform, TransformedBbox,
TransformedPath
File
"/home/gsever/Desktop/python-repo/matplotlib/lib/matplotlib/transforms.py",
line 34, in
from matplotlib._path import affine_transform
ImportError: No module named _path
Anyways, back to the main point. First remove the numpy 1.3.x:
[r...@ccn site-packages]# rm -rf numpy
[r...@ccn site-packages]# rm -rf numpy-1.3.1.dev8031-py2.6.egg-info
and install from the lates
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 11:16 AM, Gökhan Sever wrote:
>
>
> On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern wrote:
>
>> On Mon, Dec 28, 2009 at 11:00, Gökhan Sever
>> 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 11:07 AM, Robert Kern wrote: > On Mon, Dec 28, 2009 at 11:00, Gökhan Sever 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 11:00, Gökhan Sever 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Mon, Dec 28, 2009 at 10:31 AM, Gökhan Sever wrote: > > > On Sat, Dec 26, 2009 at 6:09 PM, David Cournapeau wrote: > >> On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever >> 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 >> ___ >> 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Sat, Dec 26, 2009 at 6:09 PM, David Cournapeau wrote: > On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever > 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 > ___ > 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Sun, Dec 27, 2009 at 6:19 AM, Gökhan Sever 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Sat, Dec 26, 2009 at 4:15 PM, Charles R Harris wrote: > > > On Sat, Dec 26, 2009 at 2:19 PM, Gökhan Sever wrote: > >> >> >> On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau wrote: >> >>> On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever >>> wrote: >>> > >>> > >>> > On Tue, Dec 22, 2009 at 9: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 >>> > >>> > 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: >> >> [gse...@ccn ~]$ pwd >> /home/gsever >> [gse...@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 "", line 1, in >> File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line >> 123, in >> 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() [gse...@ccn Desktop]$ pwd /home/gsever/Desktop > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Gökhan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Sat, Dec 26, 2009 at 2:19 PM, Gökhan Sever wrote: > > > On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau wrote: > >> On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever >> wrote: >> > >> > >> > On Tue, Dec 22, 2009 at 9: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 >> > >> > 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: > > [gse...@ccn ~]$ pwd > /home/gsever > [gse...@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 "", line 1, in > File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line > 123, in > 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Thu, Dec 24, 2009 at 4:57 PM, David Cournapeau wrote: > On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever > wrote: > > > > > > On Tue, Dec 22, 2009 at 9: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 > > > > 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: [gse...@ccn ~]$ pwd /home/gsever [gse...@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 "", line 1, in File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 123, in 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Wed, Dec 23, 2009 at 11:54 PM, Bruce Southey 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Wed, Dec 23, 2009 at 1:41 AM, Gökhan Sever wrote: > > > On Tue, Dec 22, 2009 at 9: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 > > 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On 12/22/2009 09:53 PM, David Cournapeau wrote: > On Wed, Dec 23, 2009 at 12:50 AM, Bruce Southey 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Wed, Dec 23, 2009 at 4:40 AM, Pauli Virtanen 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Wed, Dec 23, 2009 at 12:50 AM, Bruce Southey 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
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Tue, Dec 22, 2009 at 2:42 PM, Pauli Virtanen 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Tue, Dec 22, 2009 at 12:40 PM, Pauli Virtanen 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Tue, Dec 22, 2009 at 8:50 AM, Bruce Southey 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 segmentationfault 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
On Tue, Dec 22, 2009 at 9: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 > 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 [gse...@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. >>> import numpy Traceback (most recent call last): File "", line 1, in File "/home/gsever/Desktop/python-repo/numpy/numpy/__init__.py", line 132, in import add_newdocs File "/home/gsever/Desktop/python-repo/numpy/numpy/add_newdocs.py", line 9, in from lib import add_newdoc File "/home/gsever/Desktop/python-repo/numpy/numpy/lib/__init__.py", line 4, in from type_check import * File "/home/gsever/Desktop/python-repo/numpy/numpy/lib/type_check.py", line 8, in import numpy.core.numeric as _nx File "/home/gsever/Desktop/python-repo/numpy/numpy/core/__init__.py", line 6, in 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [ANN] numpy 1.4.0 rc2
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 segmentationfault 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
--- numpyos.c 2009-12-22 09:36:58.0 -0600
+++ ../numpy-1.4.0rc2/numpy/core/src/multiarray/numpyos.c 2009-12-22
09:44:04.0 -0600
@@ -506,7 +506,11 @@
}
memcpy(buffer, s, n);
buffer[n] = '\0';
+#if PY_VERSION_HEX >= 0x0207
+result = PyOS_string_to_double(buffer, &q, NULL);
+#else
result = PyOS_ascii_strtod(buffer, &q);
+#endif
if (endptr != NULL) {
*endptr = (char*)(s + (q - buffer));
}
@@ -515,7 +519,11 @@
}
/* End of ##2 */
+#if PY_VERSION_HEX >= 0x0207
+return PyOS_string_to_double(s, endptr, NULL);
+#else
return PyOS_ascii_strtod(s, endptr);
+#endif
}
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
