Re: [Numpy-discussion] Problem with numpy and distutils on OS X
Thanks, Robert. Indeed, numpy 1.0.4 does some monkeypatching (see the transcript below). Interestingly, 1.0.3 did not, so I'm hoping that 1.0.5 may not also. (I'd rather stay with released version, since I distribute my code to colleagues, and cannot impose too many conditions on them.) In the meantime I'll get the numpy include directory information some other way in my setup.py. I will also investigate if gcc could be smarter about enabling vectorization (perhaps in a version newer than 4.0.1?), and let you know. Cheers, Michele --- Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) [GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin Type help, copyright, credits or license for more information. import sys old = set(sys.modules) import numpy numpy.get_include() '/Users/vallis/lib/python2.5/site-packages/numpy-1.0.4-py2.5-macosx-10.3-fat.egg/numpy/core/include' new = set(sys.modules) [x for x in (new - old) if 'distutils' in x] ['numpy.distutils.misc_util', 'distutils', 'numpy.distutils.re', 'numpy.distutils.numpy', 'distutils.dep_util', 'numpy.distutils.ccompiler', 'distutils.types', 'numpy.distutils.exec_command', 'numpy.distutils.tempfile', 'distutils.re', 'numpy.distutils.info', 'numpy.distutils.distutils', 'distutils.log', 'distutils.copy', 'distutils.version', 'numpy.distutils', 'distutils.sysconfig', 'numpy.distutils.curses', 'numpy.distutils.copy', 'numpy.distutils.sys', 'numpy.distutils.__version__', 'distutils.os', 'distutils.ccompiler', 'numpy.distutils.string', 'distutils.spawn', 'distutils.sys', 'distutils.dir_util', 'numpy.distutils.unixccompiler', 'distutils.util', 'distutils.string', 'numpy.distutils.new', 'numpy.distutils.imp', 'numpy.distutils.__config__', 'distutils.distutils', 'distutils.unixccompiler', 'numpy.distutils.log', 'numpy.distutils.os', 'numpy.distutils.glob', 'numpy.distutils.atexit', 'distutils.errors', 'distutils.file_util'] --- Discussion of Numerical Python numpy-discussion@scipy.org wrote: On Fri, May 9, 2008 at 11:17 AM, Michele Vallisneri [EMAIL PROTECTED] wrote: I'm writing a standard distutils setup.py to compile a Python C extension on OS X 10.4, and I need to specify a few special compiler options to enable vector CPU extension (altivec and SSE on i686 and PPC respectively). This compromises the generation of universal binaries, because these options are CPU-specific, and cannot be passed to gcc together with -arch ppc -arch i386. I'm happy with generating a nonuniversal extension, which I can do (at least with distutils 2.4.4) by specifying an extra -arch i386 compiler option. Distutils has some Darwin-specific code that catches that, and takes out the -arch ppc option that would be there by default. All well, but then in my setup.py I also import numpy (to find out where its C includes are). If I do that, the behavior of distutils changes, and the -arch ppc option is not taken out, so compilation fails again. So I have questions: - Is this an acceptable behavior for numpy to have? No. We've seen this before, and I thought we fixed it, but perhaps not. numpy.distutils does monkeypatch distutils, but you shouldn't get that unless if you import numpy.distutils. Should it modify other modules? I understand that there is a numpy.distutils, but shouldn't I have a choice to use it explicitly, and get the old distutils behavior by using that namespace? Yes, you should be able to avoid this by avoiding importing numpy.distutils. However, I don't see why you are getting this. Just importing numpy and calling numpy.get_include() does not bring in numpy.distutils, at least not with the SVN version of numpy (the 1.1.x branch rather than the 1.2.x trunk). import sys old = set(sys.modules) import numpy numpy.get_include() '/Users/rkern/svn/numpy/numpy/core/include' new = set(sys.modules) [x for x in (new - old) if 'distutils' in x] [] You might try something similar at the top of your setup.py script to see if 1.0.4 does something different. - Is there a way to avoid or disable this interference? Possibly upgrade to the 1.1.x branch. Check it out from here: http://svn.scipy.org/svn/numpy/branches/1.1.x - Finally, is there a way to compile universal binaries with CPU- specific options? Not to my knowledge, no. There might be a gcc option to use in extra_compile_args, but you will have to check the man page for it. If you find one, please post it, since I am interested in having such a capability myself. -- 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://projects.scipy.org/mailman/listinfo/numpy-discussion ___
[Numpy-discussion] More help with numpy and SWIG
Hello,
I am trying to use numpy in conjuction with a custom SWIGged C struct
(real_vec_t) that contains array data. I'd like to use the array interface
to share the array data between real_vec_t and numpy. I have two questions
for a combined numpy/SWIG magician:
- This is how I implement the array
interface in real_vec_t, so that if rvt is a real_vec_t instance, I can do
na = numpy.array(rvt) and get a numpy array with the same content. I define
the python attribute,
%extend real_vec_t {
%pythoncode %{
__array_struct__
= property(get_array_struct,doc='Array protocol')
%}
[...]
%}
which
calls the C function (thanks to Lisandro Dalcin for suggesting this)
%extend
real_vec_t {
PyObject *get_array_struct() {
[...create the PyArrayInterface
pointed to by inter...]
[...do Py_INCREF(self) (see below)...]
[...return PyCObject pointing to inter (see below)...]
}
%}
I have problems with the last two steps. I'm supposed to do a Py_INCREF on
the SWIG object so that the array data is preserved until all numpy arrays
that may come to use it are destroyed. But I don't think it's correct to say
Py_INCREF(self), because in this context self is a pointer to a real_vec_t
structure, not the SWIG PyObject that wraps it... how should I call Py_INCREF?
I have a related problem for the last step. I'm supposed to return
PyCObject_FromVoidPtrAndDesc(inter,self,inter_free),
where inter is the pointer to the PyArrayInterface, inter_free points to a
function that will free any memory allocated with the PyArrayInterface, and
self, again, should be a pointer to the SWIG wrapper, not just the real_vec_t
C struct.
- The second question is about the conditions under which the
data pointed to by PyArrayInterface is shared with the numpy array I create
with numpy.array(rvt), or it is copied. Is this a function of the flags I
set in PyArrayInterface, of flags that must be passed to numpy.array(), or
both? I couldn't quite dig this out of the numpy manual (but will happily
take a pointer to the discussion therein...)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about standalone small software and teaching
Hello Gael (numpy friends), I'd love to use Traits and TraitsUI. It looks like a very promising approach. But why is it so difficult to install? If I download the source from http://code.enthought.com/traits/, and follow the instructions in enthought.traits-1.1.0/README, and then run the code snippet #1 in your tutorial, I get --- begin error message --- /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/pyface/util/python_stc.py:14: DeprecationWarning: The wxPython compatibility package is no longer automatically generated or activly maintained. Please switch to the wx package as soon as possible. from wxPython.wx import * Traceback (most recent call last): File prova.py, line 23, in ? camera.configure_traits() File enthought/traits/has_traits.py, line 1871, in configure_traits File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/toolkit.py, line 134, in view_application import view_application File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/view_application.py, line 29, in ? from enthought.debug.fbi \ File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/debug/fbi.py, line 257, in ? auto_size = False File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/editors.py, line 196, in TableEditor return toolkit().table_editor( *args, **traits ) File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/wx/toolkit.py, line 514, in table_editor return te.ToolkitEditorFactory( *args, **traits ) File /Users/vallis/Desktop/enthought.traits-1.1.0/enthought/traits/ui/editor_factory.py, line 55, in __init__ HasPrivateTraits.__init__( self, **traits ) File enthought/traits/trait_handlers.py, line 172, in error enthought.traits.trait_errors.TraitError: The 'selection_color' trait of a ToolkitEditorFactory instance must be a wx.Colour instance, an integer which in hex is of the form 0xRRGGBB, where RR is red, GG is green, and BB is blue, but a value of black was specified. --- end error message --- BTW, I'm using Python 2.4.4 on Macintel, with wxPython-2.8.0. If I get the latest SVN of the enthought tool suite, go to enthought/src/lib/enthought/traits, and build with python setup.py build_src build_clib build_ext --inplace as suggested in the enthought wiki, and then add enthought/src/lib to my PYTHONPATH, then your snippet fails with --- begin error message --- Traceback (most recent call last): File prova.py, line 5, in ? class Camera(HasTraits): NameError: name 'HasTraits' is not defined --- end error message --- Last, I see that matplotlib includes some enthought/traits code, but not the ui frontends. Why is that? Is the matplotlib traits usable? As you can see, I'm very confused... if only there was a traits Python egg... Thanks! Michele --- Discussion of Numerical Python numpy-discussion@scipy.org wrote: You can do a script with a GUI front end, as described in the first chapter of my tutorial http://gael-varoquaux.info/computers/traits_tutorial/traits_tutorial.html . You can also build a complete interactive application, as described in the rest of the tutorial, but this is more work. If you have more questions about this approach feal free to ask. Ga�l ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] question about standalone small software and teaching
--- Discussion of Numerical Python numpy-discussion@scipy.org wrote: [EMAIL PROTECTED] wrote: BTW, I'm using Python 2.4.4 on Macintel, with wxPython-2.8.0. We require wxPython 2.6 at the moment. Ah, good to know. This could explain the errors I get when compiling in place. If I get the latest SVN of the enthought tool suite, go to enthought/src/lib/enthought/traits, and build with python setup.py build_src build_clib build_ext --inplace as suggested in the enthought wiki, and then add enthought/src/lib to my PYTHONPATH, then your snippet fails with --- begin error message --- Traceback (most recent call last): File prova.py, line 5, in ? class Camera(HasTraits): NameError: name 'HasTraits' is not defined Hmm, it works for me. Are you sure that your build is being correctly picked up? Import enthought, then print enthought.__file__. Yes, it is picking up the right one. I assume I can run the setup.py in enthought/src/lib/enthought/traits to get only traits, right? I'm not installing scipy, or anything else. As you can see, I'm very confused... if only there was a traits Python egg... There are, but only binaries for win32 at the moment. Building from source on OS X should be straightforward, though. https://svn.enthought.com/enthought/wiki/IntelMacPython25 Ok, I'll try tomorrow and let you know. Michele ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy without BLAS, LAPACK
(Reposting to numpy-discussion@scipy.org instead of the SourceForge list.) It is my understanding that Numpy has lite versions of BLAS and LAPACK that it will use if it cannot find system libraries. Is it possible to FORCE it to use the lite versions rather than existing system libraries? (Where I come from: I'm trying to install numpy in a local directory on a Beowulf cluster, which has local BLAS and LAPACK that the numpy setup finds; however, these libraries are missing some functions, so import numpy fails at numpy.linalg. The fact is that I don't need numpy.linalg at all, so I'd be very happy with the lite libraries, rather than going to the trouble of recompiling BLAS and LAPACK or ATLAS, etc.) Michele ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
