[SciPy-dev] poll for renaming scipy_core online

Fernando Perez Fernando.Perez at colorado.edu
Tue Jan 3 00:07:32 CST 2006

eric jones wrote:

>>I think it's worth mentioning that weave up to the transition into the new 
>>scipy (I haven't really checked since) was working fairly well.  All the bugs 
>>I had been seeing related to either compiler warnings or spurious 
>>recompilations had been fixed, and with the inclusion of the blitz 0.9 
>>sources, things work even with gcc4.  So this isn't really a major development 
>>commitment, but rather one of 'being there' if the need arises, I think.
> Thanks for the info.  Have you tried it out with scipy_core arrays?  
> Does it work with these now?

I'm going to give a half-assed answer, because I haven't really played with 
weave in the new code yet (all my production stuff was still using scipy-old; 
once we move to the numerix stable naming scheme, I'll begin testing a port). 
  But a _quick_ and dirty test with an up-to-the-minute SVN copy shows there 
are problems:

In [6]: weave.inline('std::cout << "hello\\n";')
<weave: compiling>
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
/home/fperez/.python24_compiled/sc_23f50baa189f86f27c668f2d0fcfd7df0.cpp: In 
member function `void 
numpy_type_handler::conversion_numpy_check_type(PyArrayObject*, int, const 
error: `PyArray_EquivalentTypenums' undeclared (first use this function)
error: (Each undeclared identifier is reported only once for each function it 
appears in.)
/home/fperez/.python24_compiled/sc_23f50baa189f86f27c668f2d0fcfd7df0.cpp: In 
member function `void numpy_type_handler::numpy_check_type(PyArrayObject*, 
int, const char*)':
error: `PyArray_EquivalentTypenums' undeclared (first use this function)

blah blah blah.

None of the files in the examples/ directory (it seems they are the same from 
the old scipy, as they still bear your name and paths in the comments) seem to 
work at all (I didn't really tried them all, but several failed, and given 
that the simple 'hello world' above doesn't compile tells me a lot).

However, I'd be surprised if this were all that hard to fix.  The major 
underpinnings of weave don't really need to change, and the underlying C 
structure of the new numerix arrays isn't all that different (in their 
simplest form) to the old.  A blitz constructor is little more than a few 
integers indicating the dimensions/strides and a raw pointer to the memory buffer.

Perhaps Travis or someone more familiar with the current code at the C level 
can give a better evaluation of how much would be needed to make this work.

I'd suggest that as a simple starting point, the test suite could just call 
all the scripts in weave/examples.  Even if we don't check their numerical 
results yet, just seeing that they compile would be a testing advance.

Obviously, some work does need to be done, and we all know that takes time.



More information about the Scipy-dev mailing list