On Tue, May 5, 2015 at 1:52 PM, Alexander Brezinov <
alexander.brezi...@mmbresearch.com> wrote:
> Hello
>
> The import of scipy.linalg is hanging in DOUBLE_mutiply function
> (BINARY_LOOP) in umath.so. After attaching the gdb and dumping the local
> varibles the args are empty strings. Could you p
Hello
The import of scipy.linalg is hanging in DOUBLE_mutiply function
(BINARY_LOOP) in umath.so. After attaching the gdb and dumping the local
varibles the args are empty strings. Could you please advise if this is
known issue? I just search the mailing list and could not find any solution
for th
On Aug 11, 2013 4:37 PM, "Andrew Dalke" wrote:
>
> On Aug 11, 2013, at 10:24 PM, Benjamin Root wrote:
> > The idea would be that within numpy (and we should fix SciPy as well),
we would always import numpy._testing as testing, and not import testing.py
ourselves.
>
> The problem is the existing co
On Sun, Aug 11, 2013 at 2:24 PM, Benjamin Root wrote:
>
> On Aug 11, 2013 5:02 AM, "Ralf Gommers" wrote:
> >
> >
> >
> >
> > On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root wrote:
> >>
> >> Would there be some sort of way to detect that numpy.testing wasn't
> explicitly imported and issue a depr
On Aug 11, 2013, at 10:24 PM, Benjamin Root wrote:
> The idea would be that within numpy (and we should fix SciPy as well), we
> would always import numpy._testing as testing, and not import testing.py
> ourselves.
The problem is the existing code out there which does:
import numpy as np
...
n
On Aug 11, 2013 5:02 AM, "Ralf Gommers" wrote:
>
>
>
>
> On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root wrote:
>>
>> Would there be some sort of way to detect that numpy.testing wasn't
explicitly imported and issue a deprecation warning? Say, move the code
into numpy._testing, import in into the
On Sun, Aug 11, 2013 at 3:35 AM, Benjamin Root wrote:
> Would there be some sort of way to detect that numpy.testing wasn't
> explicitly imported and issue a deprecation warning? Say, move the code
> into numpy._testing, import in into the namespace as testing, but then have
> the testing.py file
On Aug 10, 2013 12:50 PM, "Ralf Gommers" wrote:
>
>
>
>
> On Sat, Aug 10, 2013 at 5:21 PM, Andrew Dalke
wrote:
>>
>> [Short version: It doesn't look like my proposal or any
>> simple alternative is tenable.]
>>
>> On Aug 10, 2013, at 10:28 AM, Ralf Gommers wrote:
>> > It does break backwards comp
On Sat, Aug 10, 2013 at 5:21 PM, Andrew Dalke wrote:
> [Short version: It doesn't look like my proposal or any
> simple alternative is tenable.]
>
> On Aug 10, 2013, at 10:28 AM, Ralf Gommers wrote:
> > It does break backwards compatibility though, because now you can do:
> >
> >import numpy a
[Short version: It doesn't look like my proposal or any
simple alternative is tenable.]
On Aug 10, 2013, at 10:28 AM, Ralf Gommers wrote:
> It does break backwards compatibility though, because now you can do:
>
>import numpy as np
>np.testing.assert_equal(x, y)
Yes, it does.
I realize
On Wed, Aug 7, 2013 at 3:26 PM, Andrew Dalke wrote:
> On Aug 7, 2013, at 4:37 AM, Charles R Harris wrote:
> > I haven't forgotten and intend to look at it before the next release.
>
> Thanks!
>
> On a related topic, last night I looked into deferring the
> import for numpy.testing. This is the onl
On Aug 7, 2013, at 4:37 AM, Charles R Harris wrote:
> I haven't forgotten and intend to look at it before the next release.
Thanks!
On a related topic, last night I looked into deferring the
import for numpy.testing. This is the only other big place
where numpy's import overhead might be reduced
Hello,
On 10/04/2013 11:13, Anand Gadiyar wrote:
On Friday, April 5, 2013, Anand Gadiyar wrote:
Hi all,
I have a small program that uses numpy and scipy. I ran into a
couple of errors while trying to use cxfreeze to create a
windows executable.
I'm run
Hi Brad,
On Fri, Apr 5, 2013 at 8:33 PM, Bradley M. Froehle
wrote:
> Hi Anand,
>
> On Friday, April 5, 2013, Anand Gadiyar wrote:
>
>> Hi all,
>>
>> I have a small program that uses numpy and scipy. I ran into a couple of
>> errors while trying to use cxfreeze to create a windows executable.
>>
>
Hi Anand,
On Friday, April 5, 2013, Anand Gadiyar wrote:
> Hi all,
>
> I have a small program that uses numpy and scipy. I ran into a couple of
> errors while trying to use cxfreeze to create a windows executable.
>
> I'm running Windows 7 x64, Python 2.7.3 64-bit, Numpy 1.7.1rc1 64-bit,
> Scipy-
Hi all,
I have a small program that uses numpy and scipy. I ran into a couple of
errors while trying to use cxfreeze to create a windows executable.
I'm running Windows 7 x64, Python 2.7.3 64-bit, Numpy 1.7.1rc1 64-bit,
Scipy-0.11.0 64-bit, all binary installs from <
http://www.lfd.uci.edu/~gohlk
On 10 July 2012 09:05, Andrew Dalke wrote:
> On Jul 8, 2012, at 9:22 AM, Scott Sinclair wrote:
>> On 6 July 2012 15:48, Andrew Dalke wrote:
>>> I followed the instructions at
>>> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
>>> and added Ticket #2181 (with patch) ...
>>
>> Those ins
Andrew,
Thank you for your comments. I agree it's confusing coming to github at
first. I still have to refer to the jargon-file to understand what everything
means. There are a lot of unfamiliar terms.
Thank you for your patches. It does imply more work for developers on NumPy,
whic
On Jul 8, 2012, at 9:22 AM, Scott Sinclair wrote:
> On 6 July 2012 15:48, Andrew Dalke wrote:
>> I followed the instructions at
>> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
>> and added Ticket #2181 (with patch) ...
>
> Those instructions need to be updated to reflect the current
On 6 July 2012 15:48, Andrew Dalke wrote:
> I followed the instructions at
> http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
> and added Ticket #2181 (with patch) at
> http://projects.scipy.org/numpy/ticket/2181
Those instructions need to be updated to reflect the current preferred
pr
I followed the instructions at
http://docs.scipy.org/doc/numpy/dev/gitwash/patching.html
and added Ticket #2181 (with patch) at
http://projects.scipy.org/numpy/ticket/2181
This remove the 5 'exec' calls from polynomial/*.py and improves
the 'import numpy' time by about 25-30%. That is, on my lap
On Tue, Jul 3, 2012 at 1:16 AM, Andrew Dalke wrote:
> On Jul 3, 2012, at 12:46 AM, David Cournapeau wrote:
> > It is indeed irrelevant to your end goal, but it does affect the
> > interpretation of what import_array does, and thus of your benchmark
>
> Indeed.
>
> > Focusing on polynomial seems th
On Mon, Jul 2, 2012 at 2:59 PM, Nathaniel Smith wrote:
> On Mon, Jul 2, 2012 at 10:06 PM, Robert Kern wrote:
>> On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>>>
>>> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>>
I think this ship has sailed, but it'd be worth looking int
On Mon, Jul 2, 2012 at 12:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%.
+1 -- I think I remember that thread -- a
On Jul 3, 2012, at 12:46 AM, David Cournapeau wrote:
> It is indeed irrelevant to your end goal, but it does affect the
> interpretation of what import_array does, and thus of your benchmark
Indeed.
> Focusing on polynomial seems the only sensible action. Except for
> test, all the other stuff se
On Jul 3, 2012, at 12:21 AM, Nathaniel Smith wrote:
> Yes, but for a proper benchmark we need to compare this to the number
> that we would get with some other implementation... I'm assuming you
> aren't proposing we just delete the docstrings :-).
I suspect that we have a different meaning of the
On Mon, Jul 2, 2012 at 11:15 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
>> No, that's the wrong thing to test, because it effectively amounts to
>> 'import numpy', sicne the numpy __init__ file is still executed. As
>> David indicated, you must import multarray.s
On Mon, Jul 2, 2012 at 11:15 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
>> No, that's the wrong thing to test, because it effectively amounts to
>> 'import numpy', sicne the numpy __init__ file is still executed. As
>> David indicated, you must import multarray.s
On Mon, Jul 2, 2012 at 3:15 PM, Andrew Dalke wrote:
>
> Thus, I don't see any way that I can import 'multiarray' directly,
> because the underlying C code is the one which imports
> 'numpy.core.multiarray' and by design it is inaccessible to change
> from Python code.
I was just referring to how
On Mon, Jul 2, 2012 at 10:44 PM, Andrew Dalke wrote:
> On Jul 2, 2012, at 10:34 PM, Nathaniel Smith wrote:
>> I don't have any opinion on how acceptable this would be, but I also
>> don't see a benchmark showing how much this would help?
>
> The profile output was lower in that email. The relevant
On Jul 2, 2012, at 11:38 PM, Fernando Perez wrote:
> No, that's the wrong thing to test, because it effectively amounts to
> 'import numpy', sicne the numpy __init__ file is still executed. As
> David indicated, you must import multarray.so by itself.
I understand that clarification. However, it
On Mon, Jul 2, 2012 at 10:06 PM, Robert Kern wrote:
> On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>>
>> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>
>>> I think this ship has sailed, but it'd be worth looking into lazy
>>> importing, where 'numpy.fft' isn't actually imported
On Jul 2, 2012, at 10:34 PM, Nathaniel Smith wrote:
> I don't have any opinion on how acceptable this would be, but I also
> don't see a benchmark showing how much this would help?
The profile output was lower in that email. The relevant line is
0.038 add_newdocs (numpy.core.multiarray)
This say
On Mon, Jul 2, 2012 at 2:26 PM, Andrew Dalke wrote:
>
> so the relevant timing test is more likely:
>
> % time python -c 'import numpy.core.multiarray'
> 0.086u 0.031s 0:00.12 91.6% 0+0k 0+0io 0pf+0w
No, that's the wrong thing to test, because it effectively amounts to
'import numpy', sicne t
On Jul 2, 2012, at 10:33 PM, David Cournapeau wrote:
> On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke
> wrote:
>> In July of 2008 I started a thread about how "import numpy"
>> was noticeably slow for one of my customers.
...
>> I managed to get the import time down from 0.21 seconds to
>> 0.08
02.07.2012 21:17, Andrew Dalke kirjoitti:
[clip]
> 1) remove "add_newdocs" and put the docstrings in the C code
> 'add_newdocs' still needs to be there,
The docstrings need to be in an easily parseable format, because of the
online documentation editor. Keeping the current format may be the
easie
On Mon, Jul 2, 2012 at 9:43 PM, Benjamin Root wrote:
>
> On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
>> I think this ship has sailed, but it'd be worth looking into lazy
>> importing, where 'numpy.fft' isn't actually imported until someone
>> starts using it. There are a bunch of libr
On Mon, Jul 2, 2012 at 4:34 PM, Nathaniel Smith wrote:
> On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke
> wrote:
> > In this email I propose a few changes which I think are minor
> > and which don't really affect the external NumPy API but which
> > I think could improve the "import numpy" perform
On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%. This affects me because I and my clients us
On Mon, Jul 2, 2012 at 8:17 PM, Andrew Dalke wrote:
> In this email I propose a few changes which I think are minor
> and which don't really affect the external NumPy API but which
> I think could improve the "import numpy" performance by at
> least 40%. This affects me because I and my clients us
In this email I propose a few changes which I think are minor
and which don't really affect the external NumPy API but which
I think could improve the "import numpy" performance by at
least 40%. This affects me because I and my clients use a
chemistry toolkit which uses only NumPy arrays, and where
Yes, you're right. The problem is, when you use the first one, you may cause
a 'name pollution' to the current namespace.
read this: http://bytebaker.com/2008/07/30/python-namespaces/
cheers,
Chao
2011/7/19 Alex Ter-Sarkissov
> this is probably silly question, I've seen in this in one of the
this is probably silly question, I've seen in this in one of the tutorials:
from tkinter import *
import tkinter.messagebox
given that * implies importing the whole module, why would anyone bother
with importing a specific command on top of it?
___
Nu
This is due to a mismatch of the UCS mode of Python and the
C extension you build. Python has a configure option to let you
choose whether unicode symbols are represented as 2 of 4 bytes,
i.e. UCS2 or UCS4.
- Ilan
On Wed, Jun 8, 2011 at 3:07 PM, Raymond Roberts wrote:
> numpy.__version__ == 2.
numpy.__version__ == 2.0.0.dev-76ca55f
python version 2.7.1
Gentoo Linux 2.6.38-r6 installed inside of VMWare fusion on Mac OS X 10.6.7
gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5
Build is successful. Import of numpy dev build results in the following
error message
ImportError: ~/numpy/lib/python/n
On Mon, Apr 4, 2011 at 9:33 AM, Charles R Harris
wrote:
>
>
> On Mon, Apr 4, 2011 at 8:57 AM, Paul Anton Letnes <
> paul.anton.let...@gmail.com> wrote:
>
>>
>> On 4. apr. 2011, at 16.42, Charles R Harris wrote:
>>
>> >
>> >
>> > On Mon, Apr 4, 2011 at 8:29 AM, Paul Anton Letnes <
>> paul.anton.let
On Mon, Apr 4, 2011 at 8:57 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
>
> On 4. apr. 2011, at 16.42, Charles R Harris wrote:
>
> >
> >
> > On Mon, Apr 4, 2011 at 8:29 AM, Paul Anton Letnes <
> paul.anton.let...@gmail.com> wrote:
> >
> > On 4. apr. 2011, at 15.34, Charles R Harris
On 4. apr. 2011, at 16.42, Charles R Harris wrote:
>
>
> On Mon, Apr 4, 2011 at 8:29 AM, Paul Anton Letnes
> wrote:
>
> On 4. apr. 2011, at 15.34, Charles R Harris wrote:
>
> >
> >
> > On Sun, Apr 3, 2011 at 4:35 AM, Paul Anton Letnes
> > wrote:
> > Hi.
> >
> > When looking at the loadtxt
On Mon, Apr 4, 2011 at 8:29 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
>
> On 4. apr. 2011, at 15.34, Charles R Harris wrote:
>
> >
> >
> > On Sun, Apr 3, 2011 at 4:35 AM, Paul Anton Letnes <
> paul.anton.let...@gmail.com> wrote:
> > Hi.
> >
> > When looking at the loadtxt/savetxt
On 4. apr. 2011, at 15.34, Charles R Harris wrote:
>
>
> On Sun, Apr 3, 2011 at 4:35 AM, Paul Anton Letnes
> wrote:
> Hi.
>
> When looking at the loadtxt/savetxt tickets, I noticed that the 're' module
> is imported in an odd place. I therefore suggest that this import is moved to
> the to
On Sun, Apr 3, 2011 at 4:35 AM, Paul Anton Letnes <
paul.anton.let...@gmail.com> wrote:
> Hi.
>
> When looking at the loadtxt/savetxt tickets, I noticed that the 're' module
> is imported in an odd place. I therefore suggest that this import is moved
> to the top of the file, in order to gather th
Hi.
When looking at the loadtxt/savetxt tickets, I noticed that the 're' module is
imported in an odd place. I therefore suggest that this import is moved to the
top of the file, in order to gather these as much as possible. I find the code
easier to read then. After all, there is no 'try / cat
On Sun, Mar 13, 2011 at 6:08 AM, Joshua Holbrook
wrote:
> Sup y'all,
>
> I just installed numpy from github, but when I tried to import it I
> got some odd errors! What's going on, and how can it be fixed?
Are you in the numpy source tree when trying that command? If not, try
to clean ("git clean
Sup y'all,
I just installed numpy from github, but when I tried to import it I
got some odd errors! What's going on, and how can it be fixed?
josh@pidgey:~$ python -c 'import numpy; numpy.test()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.6/dist-pack
On Tue, Dec 22, 2009 at 5:29 AM, Chris wrote:
> David Cournapeau gmail.com> writes:
>
>>
>> Ok, so the undefined functions all indicate that the most recently
>> implemented ones are not included. I really cannot see any other
>> explanation that having a discrepancy between the source tree, buil
On Mon, Dec 21, 2009 at 1:29 PM, Chris wrote:
> David Cournapeau gmail.com> writes:
>
> >
> > Ok, so the undefined functions all indicate that the most recently
> > implemented ones are not included. I really cannot see any other
> > explanation that having a discrepancy between the source tree,
David Cournapeau gmail.com> writes:
>
> Ok, so the undefined functions all indicate that the most recently
> implemented ones are not included. I really cannot see any other
> explanation that having a discrepancy between the source tree, build
> tree and installation. Sometimes, svn screw thing
Chris gmail.com> writes:
>
> By the way, I tried building 1.4rc1 and the same thing happens.
>
... however, I was am able to get a usable build from r7542. Not sure
how much more recent I can go before failures occurred. Somewhere
between 7543 and 7726.
__
David Cournapeau gmail.com> writes:
>
> Ok, so the undefined functions all indicate that the most recently
> implemented ones are not included. I really cannot see any other
> explanation that having a discrepancy between the source tree, build
> tree and installation. Sometimes, svn screw thing
David Cournapeau gmail.com> writes:
>
> Could you give us the generated config.h (somewhere in
> build/src.*/numpy/core/), just in case ?
>
Here it is:
http://files.me.com/fonnesbeck/d9eyxi
Thanks again.
cf
___
NumPy-Discussion mailing list
Num
On Mon, Dec 14, 2009 at 5:29 AM, Chris wrote:
> Chris gmail.com> writes:
>
>> Here it is:
>>
>> http://files.me.com/fonnesbeck/6ezhy5
>>
>
> Sorry, that link should be:
>
> http://files.me.com/fonnesbeck/qv8o59
Ok, so the undefined functions all indicate that the most recently
implemented ones a
Chris gmail.com> writes:
> Here it is:
>
> http://files.me.com/fonnesbeck/6ezhy5
>
Sorry, that link should be:
http://files.me.com/fonnesbeck/qv8o59
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinf
David Cournapeau gmail.com> writes:
> could you show the output from nm on umath.so, to check what
> symbols are missing. Maybe seeing the whole list would bring
> something.
Here it is:
http://files.me.com/fonnesbeck/6ezhy5
The symbol in question is in there, but I see that it does not
have
On Sun, Dec 13, 2009 at 12:55 PM, Robert Kern wrote:
>> I don't see any build error on this log ?
>
> See earlier in the thread. The error occurs at runtime:
Right.
Chris, could you show the output from nm on umath.so, to check what
symbols are missing. Maybe seeing the whole list would bring
s
On Sun, Dec 13, 2009 at 00:37, David Cournapeau wrote:
> On Sun, Dec 13, 2009 at 4:27 AM, Chris wrote:
>> Here is a log form a build of svn rev 7996 with no LDFLAGS specified, as
>> recommended by Robert. The result is the same, however.
>>
>> http://files.me.com/fonnesbeck/y7e9v2
>
> I don't see
On Sun, Dec 13, 2009 at 4:27 AM, Chris wrote:
> Here is a log form a build of svn rev 7996 with no LDFLAGS specified, as
> recommended by Robert. The result is the same, however.
>
> http://files.me.com/fonnesbeck/y7e9v2
I don't see any build error on this log ?
David
___
Here is a log form a build of svn rev 7996 with no LDFLAGS specified, as
recommended by Robert. The result is the same, however.
http://files.me.com/fonnesbeck/y7e9v2
cf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.or
> From: David Cournapeau
> >> Does the file
> >> /usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so exist ?
> >>
> >> cheers,
> >>
> >> David
> >
> >
> > Indeed, this file is not there. Where can I find it?
>
> My mistake, cygwin uses the same extension as windows, that is .dll
> and no
On Thu, Dec 3, 2009 at 5:41 AM, Olivia Cheronet
wrote:
> - Original Message
>> From: David Cournapeau
>>
>> Does the file
>> /usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so exist ?
>>
>> cheers,
>>
>> David
>
>
> Indeed, this file is not there. Where can I find it?
My mista
On Thu, Dec 3, 2009 at 5:41 AM, Olivia Cheronet
wrote:
> - Original Message
>> From: David Cournapeau
>>
>> Does the file
>> /usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so exist ?
>>
>> cheers,
>>
>> David
>
>
> Indeed, this file is not there. Where can I find it?
It shoul
- Original Message
> From: David Cournapeau
>
> Does the file
> /usr/lib/python2.5/site-packages/numpy/linalg/lapack_lite.so exist ?
>
> cheers,
>
> David
Indeed, this file is not there. Where can I find it?
Thanks.
Olivia
___
NumP
Olivia Cheronet wrote:
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.5/site-packages/numpy/__init__.py", line 132, in
> e>
> import add_newdocs
> File "/usr/lib/python2.5/site-packages/numpy/add_newdocs.py", line 9, in
> le>
> from lib import
Hello!
I have built numpy (updated to the trunk) for my cygwin (1.5.25) Python (2.5.2).
However, testing fails when I try to import numpy in python (see output below).
I have been searching around for a solution, but everything has failed so far...
I would be grateful for any advice.
Thank you,
Chris gmail.com> writes:
>
> Charles R Harris gmail.com> writes:
> >
> > Maybe there is a stray old file floating about somewhere.
> Chris, is there a locate command for the mac? Could you track
> down numpy related files and make sure none are sitting in some
> dusty old corner?Chuck
Add
Charles R Harris gmail.com> writes:
>
> Maybe there is a stray old file floating about somewhere.
Chris, is there a locate command for the mac? Could you track
down numpy related files and make sure none are sitting in some
dusty old corner?Chuck
>
>
Sorry to be a pain on this, but it has
On Sat, Nov 28, 2009 at 6:44 PM, David Cournapeau wrote:
> On Sun, Nov 29, 2009 at 10:02 AM, Chris wrote:
> > Chris gmail.com> writes:
> >> Nothing looks out of order, but I still get the
> >> Symbol not found: _npy_cexp
> >> errors.
> >>
> >
> > This problem still persists through rev 7803. Is
On Sun, Nov 29, 2009 at 10:02 AM, Chris wrote:
> Chris gmail.com> writes:
>> Nothing looks out of order, but I still get the
>> Symbol not found: _npy_cexp
>> errors.
>>
>
> This problem still persists through rev 7803. Is there no solution
> for this?
The problem is that I don't see this issue
Chris gmail.com> writes:
> Nothing looks out of order, but I still get the
> Symbol not found: _npy_cexp
> errors.
>
This problem still persists through rev 7803. Is there no solution
for this? I have no clue where its coming from.
Thanks in advance.
_
David Cournapeau gmail.com> writes:
> I am afraid I don't see where the problem may come from. I used the
> exact same build script as you, on the same version of mac os x, and I
> don't see the problem. Is there anything non standard in your
> environment that you can think of ?
>
Not that I ca
On Fri, Nov 13, 2009 at 4:56 AM, Chris wrote:
> David Cournapeau gmail.com> writes:
>
>>
>> On Thu, Nov 12, 2009 at 6:57 AM, Chris gmail.com> wrote:
>>
>> >
>> > Yeah, here is my build script -- it removes the build directory entirely
>>
>> Ah, that's not enough. You need to clean the working tr
David Cournapeau gmail.com> writes:
>
> On Thu, Nov 12, 2009 at 6:57 AM, Chris gmail.com> wrote:
>
> >
> > Yeah, here is my build script -- it removes the build directory entirely
>
> Ah, that's not enough. You need to clean the working tree as well. git
> has the clean option for that, you c
On Thu, Nov 12, 2009 at 6:57 AM, Chris wrote:
>
> Yeah, here is my build script -- it removes the build directory entirely
Ah, that's not enough. You need to clean the working tree as well. git
has the clean option for that, you can also use a quick script to do
this with parsing svn st output.
David Cournapeau ar.media.kyoto-u.ac.jp> writes:
>
> Did you make sure to build from scratch and clean the working directory
> first ?
>
> I don't see the error on my macbook: umath.so has npy_cexp* functions
> defined.
>
> David
>
Just now tried deleting everything and pulling down numpy aga
David Cournapeau ar.media.kyoto-u.ac.jp> writes:
> Did you make sure to build from scratch and clean the working directory
> first ?
>
> I don't see the error on my macbook: umath.so has npy_cexp* functions
> defined.
>
> David
>
Yeah, here is my build script -- it removes the build directory
Chris wrote:
> I am building Numpy on OSX 10.6 using a recent update
> from SVN (r7726). Though I was able to build the package
> successfully, the resulting package generates an ImportError:
>
> import umath
> ImportError: dlopen(/Library/Python/2.6/site-packages/
> numpy-1.4.0.dev7726-py2.6-m
I am building Numpy on OSX 10.6 using a recent update
from SVN (r7726). Though I was able to build the package
successfully, the resulting package generates an ImportError:
import umath
ImportError: dlopen(/Library/Python/2.6/site-packages/
numpy-1.4.0.dev7726-py2.6-macosx-10.6-
universal.egg/
On Sun, Jun 28, 2009 at 11:31 AM, Dinesh B
Vadhia wrote:
> The machine in question is factory installed with:
>
> OS: Windows Vista 64-bit SP2
> Processor: Intel Core2 Quad CPU, Q6600 @ 2.4Ghz @2.4GHz
> Memory: 8Gb
>
> Apart from Python 2.5.4 nothing has been installed on this machine as it is
> b
AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Import Numpy on Windows Vista x64 AMD
On Sun, Jun 28, 2009 at 2:05 AM, Dinesh B
Vadhia wrote:
> Okay. Maybe a bit harsh, but wouldn't it be better not to have the release
> as available if it cannot be imported?
It ca
On Sun, Jun 28, 2009 at 2:05 AM, Dinesh B
Vadhia wrote:
> Okay. Maybe a bit harsh, but wouldn't it be better not to have the release
> as available if it cannot be imported?
It cannot be imported in some situations, but it works fine in others.
David
_
Okay. Maybe a bit harsh, but wouldn't it be better not to have the release as
available if it cannot be imported?
From: David Cournapeau
Sent: Friday, June 26, 2009 7:00 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Import Numpy on Windows Vista x64 AMD
On Sat
On Sat, Jun 27, 2009 at 6:42 AM, Dinesh B
Vadhia wrote:
> Ticket# 1084
> (http://projects.scipy.org/numpy/timeline?from=2009-06-09T03%3A01%3A59-0500&precision=second)
> says that the numpy import on Windows Vista x64 AMD systems works now.
I mistakenly closed it as fixed, but it is just a duplicat
Ticket# 1084
(http://projects.scipy.org/numpy/timeline?from=2009-06-09T03%3A01%3A59-0500&precision=second)
says that the numpy import on Windows Vista x64 AMD systems works now. Is
this for Numpy 1.3 or 1.4 and if 1.3 has anyone tried it successfully? Thanks.
Dinesh
_
> I don't think numpy/scipy are zip safe, the numpy packageloader uses
os.path to find files.
Evidently! :-)
But the strange thing is that all this worked fine with Scipy 0.6.0 -
it's only since 0.7.0 was released that this started going wrong.
Sal
Disclaimer CALYON UK:
This email does not cre
On Fri, Jun 5, 2009 at 9:25 AM, Fadhley Salim
wrote:
> I've noticed that with scipy 0.7.0 + numpy 1.2.1, an importing the factorial
> function from the scipy module always seems to fail when scipy is installed
> as a zipped ",egg" file. When the project is installed as an unzipped
> directory it w
I've noticed that with scipy 0.7.0 + numpy 1.2.1, an importing the
factorial function from the scipy module always seems to fail when scipy
is installed as a zipped ",egg" file. When the project is installed as
an unzipped directory it works fine.
Is there any reason why this function should not
téfan van der Walt wrote:
From: Stéfan van der Walt
Subject: Re: [Numpy-discussion] Import NumPy in Self-defined function script
To: "Discussion of Numerical Python"
Date: Sunday, February 22, 2009, 6:45 PM
Hi Tim
2009/2/23 Tim :
> I think zeros belongs to Module numpy, and
Am 23.02.2009 um 00:59 schrieb Stéfan van der Walt:
> 2009/2/23 Markus Rosenstihl darmstadt.de>:
>>> Another script "controller.py" calls this function as:
>>>
>>> [code]#! /usr/bin/env python
>>> # from numpy import *
>>^ This is a comment, you are not importing numpy!
>
> But he is also not
2009/2/23 Markus Rosenstihl :
>> Another script "controller.py" calls this function as:
>>
>> [code]#! /usr/bin/env python
>> # from numpy import *
> ^ This is a comment, you are not importing numpy!
But he is also not using numpy in controller.
Cheers
Stéfan
_
On Mon, Feb 23, 2009 at 12:47:41AM +0100, Markus Rosenstihl wrote:
You are definitely right with your suggestion not to use 'from foo import *'
It took me a while to realise that the gain of explicite namespace was
more than the cost of a few characters, but I definitely stand by this.
> I always
Am 23.02.2009 um 00:19 schrieb Tim:
> Hi,
> I am defining a function in file "trainer.py". It requires a module
> called numpy as following:
>
>
> Another script "controller.py" calls this function as:
>
> [code]#! /usr/bin/env python
> # from numpy import *
^ This is a comment, you are no
1 - 100 of 197 matches
Mail list logo
