Re: [Numpy-discussion] test_multiarray.test_clip fails on Solaris 8 system
> The following test fails on a Solaris 8 system: > == > FAIL: check_basic (numpy.core.tests.test_multiarray.test_clip) > -- > Traceback (most recent call last): > [removed] > "/data/basil5/site-packages/lib/python/numpy/testing/utils.py", line > 143, in assert_equal > assert desired == actual, msg > AssertionError: > Items are not equal: > ACTUAL: '<' > DESIRED: '=' > > Hmm, Sun hardware is big endian, no? I wonder what happens on PPC? I > don't see any problems here on Athlon64. Indeed, I get the same problem on a PPC running OSX 10.4 Andrew ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dynamic module not initialized properly
Thanks for the info Greg. Yup. I am sorry that I had to post a thread
without code to back it up unfortunately, there just isn't a way for
me to roll it into an example without the entire package being
installed. This is all very good info you have provided. Ill let you
know how things work out. Thanks again,
MJ
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steele, Greg
Sent: Monday, April 02, 2007 9:07 AM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Dynamic module not initialized properly
Mark,
It is hard to comment since you have not provided much information. Your
link to a previous thread brought up a post that I had sent. The issue
that I encountered had to do with the "multiarraymodule.c" extension
module. When "numpy" is imported, it imports this module and the static
variable "_multiarray_module_loaded" gets set. When Python is finalized
is does not unload the multiarraymodule.c DLL. When Python is
initialized again and "numpy" is imported again, the static variable is
already set and multiarraymodule does not import correctly. Hence the
error.
The way I dealt with this is a 'hack', but it worked for us. This was on
a windows platform. After I finalize Python, I forcibly unload the
multiarraymodule DLL using the "FreeLibrary" call. The C code looks like
if (multiarray_loaded) {
HINSTANCE hDLL = NULL;
hDLL = LoadLibraryEx(buf, NULL,LOAD_WITH_ALTERED_SEARCH_PATH);
FreeLibrary(hDLL);
FreeLibrary(hDLL);
}
The two calls of FreeLibrary are needed since each call to LoadLibraryEx
increments the DLL reference count. The call to LoadLibraryEx here gets
a handle to the DLL.
What needs to be done long term is the removal of the static variable in
multiarraymodule. I don't understand the code well enough to know why it
is needed, but that appears to be the crux of the issue. Another
solution would be for Python to call FreeLibrary on all the DLLs during
Py_Finalize.
Greg
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Janikas
Sent: Friday, March 30, 2007 4:55 PM
To: Discussion of Numerical Python
Subject: [Numpy-discussion] Dynamic module not initialized properly
Hello all,
I am having an issue importing numpy on subsequent (I.e. not on first
load) attempts in our software. The majority of the code is written in
C, C++ and I am a python developer and do not have direct access to a
lot of it. This is a bit of a difficult question to ask all of you
because I cant provide you a direct example. All I can do is point to a
numpy thread that discusses the issue:
http://groups.google.com/group/Numpy-discussion/browse_thread/thread/321
77a82deab05ae/d8eecaf494ba5ad5?lnk=st&q=dynamic+module+not+initialized+p
roperly+numpy&rnum=1&hl=en#d8eecaf494ba5ad5
ERROR:
exceptions.SystemError: dynamic module not initialized properly
What is really odd about my specific issue is that if I don't change
anything in the source code Then the error doesn't pop up.
Furthermore, the error doesn't show on some attempts even after I make a
change Not sure whether there is anything I can do from the
scripting side (some alternative form of reload?)... or if I have to
forward it along to the C developers. You have my appreciation ahead of
time.
Mark Janikas
Product Engineer
ESRI, Geoprocessing
380 New York St.
Redlands, CA 92373
909-793-2853 (2563)
[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Dynamic module not initialized properly
Mark,
It is hard to comment since you have not provided much information. Your
link to a previous thread brought up a post that I had sent. The issue
that I encountered had to do with the "multiarraymodule.c" extension
module. When "numpy" is imported, it imports this module and the static
variable "_multiarray_module_loaded" gets set. When Python is finalized
is does not unload the multiarraymodule.c DLL. When Python is
initialized again and "numpy" is imported again, the static variable is
already set and multiarraymodule does not import correctly. Hence the
error.
The way I dealt with this is a 'hack', but it worked for us. This was on
a windows platform. After I finalize Python, I forcibly unload the
multiarraymodule DLL using the "FreeLibrary" call. The C code looks like
if (multiarray_loaded) {
HINSTANCE hDLL = NULL;
hDLL = LoadLibraryEx(buf, NULL,LOAD_WITH_ALTERED_SEARCH_PATH);
FreeLibrary(hDLL);
FreeLibrary(hDLL);
}
The two calls of FreeLibrary are needed since each call to LoadLibraryEx
increments the DLL reference count. The call to LoadLibraryEx here gets
a handle to the DLL.
What needs to be done long term is the removal of the static variable in
multiarraymodule. I don't understand the code well enough to know why it
is needed, but that appears to be the crux of the issue. Another
solution would be for Python to call FreeLibrary on all the DLLs during
Py_Finalize.
Greg
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Janikas
Sent: Friday, March 30, 2007 4:55 PM
To: Discussion of Numerical Python
Subject: [Numpy-discussion] Dynamic module not initialized properly
Hello all,
I am having an issue importing numpy on subsequent (I.e. not on first
load) attempts in our software. The majority of the code is written in
C, C++ and I am a python developer and do not have direct access to a
lot of it. This is a bit of a difficult question to ask all of you
because I cant provide you a direct example. All I can do is point to a
numpy thread that discusses the issue:
http://groups.google.com/group/Numpy-discussion/browse_thread/thread/321
77a82deab05ae/d8eecaf494ba5ad5?lnk=st&q=dynamic+module+not+initialized+p
roperly+numpy&rnum=1&hl=en#d8eecaf494ba5ad5
ERROR:
exceptions.SystemError: dynamic module not initialized properly
What is really odd about my specific issue is that if I don't change
anything in the source code Then the error doesn't pop up.
Furthermore, the error doesn't show on some attempts even after I make a
change Not sure whether there is anything I can do from the
scripting side (some alternative form of reload?)... or if I have to
forward it along to the C developers. You have my appreciation ahead of
time.
Mark Janikas
Product Engineer
ESRI, Geoprocessing
380 New York St.
Redlands, CA 92373
909-793-2853 (2563)
[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Release of NumPy 1.0.2 for Monday
El dg 01 de 04 del 2007 a les 21:35 +0200, en/na Francesc Altet va escriure: > El ds 31 de 03 del 2007 a les 21:54 -0600, en/na Travis Oliphant va > escriure: > > I'm going to be tagging the tree for the NumPy 1.0.2 release tomorrow > > evening in preparation for the release on Monday. I've closed several > > bugs. Are there any show-stoppers remaining to be fixed? > > Mmm... PyTables test suite segfaults with latest SVN. The problem is > described in #487 and I'm afraid that it is a clear stopper for us. > Sorry for running the PyTables test suite so late before the new NumPy > release. > > Also, I've found a patch for #483. Although it is not critical for us, > it would be nice if it can be added to NumPy 1.0.2 final. I've checked out r3640 and everything seems to go smoothly with Linux (32-bit and 64-bit platforms). Many thanks! -- Francesc Altet| Be careful about using the following code -- Carabos Coop. V. | I've only proven that it works, www.carabos.com | I haven't tested it. -- Donald Knuth ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
