[SciPy-dev] poll for renaming scipy_core online

[Travis Oliphant]

Fernando Perez wrote:

>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 
>char*)':
>/home/fperez/.python24_compiled/sc_23f50baa189f86f27c668f2d0fcfd7df0.cpp:488: 
>error: `PyArray_EquivalentTypenums' undeclared (first use this function)
>/home/fperez/.python24_compiled/sc_23f50baa189f86f27c668f2d0fcfd7df0.cpp:488: 
>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*)':
>/home/fperez/.python24_compiled/sc_23f50baa189f86f27c668f2d0fcfd7df0.cpp:514: 
>error: `PyArray_EquivalentTypenums' undeclared (first use this function)
>
>  
>
Doh...   Weave *was* working, but I changed the C-API a couple of 
iterations ago for consistency and this function is called something 
else.   This is an example of why I'm uncomfortable with it in the core: 
it's just not on my radar...

>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.
>
>  
>
It should work as before for the old data-types, but I doubt the new 
fancy array data-types will be handled correctly.

>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.
>  
>
Again, weave was working for simple examples before the refactoring that 
occurred in December.

-Travis