| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
Numeric arrays. If we could use std::wstring reliably on all platforms,
the need for this would go away. My notes say that it doesn't compile
correctly on gcc2.95.3 though.
|
| |
|
|
|
| |
added Linux support for wxPython. This still has quite a bit of hard coded
stuff in it because there is no easy way to query it. This will slowly improve.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added support for wxPython on Unix. Configuration information is gathered
by running wx-config with the proper flags specified (--cxxflags, --ldflags,
--libs, --gl-libs) to find libraries and include directories needed. I
wish we could query the wxPython module directly and ask it for this
information, as it would be much more robust. Currently we look in the
/usr/lib/wxPython directory for wx stuff. If it isn't there, we're out of
luck. The wxPython development files are required for this stuff to work.
Windows is actually worse. I've updated the config files to support
wx2.3.3.1. Is there a way to discover build type (ansi/unicode) from the
wxPython library? Right now, it is hard coded to use the Unicode version
of the DLLs. As for macros and libraries, I borrowed them from the make
file in the wx2.3.3.1/src/make.env file. The wxPython devel package must
be installed the c:\ directory for all of this to work.
If people use alternative directories in either case, they'll have to hand
edit the wx_spec file to deal with this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weave. The original SCXX code has been augmented and mutated to the
point of not be recognizable as SCXX any more. File and class names
have moved more toward boost naming conventions.
The most significant change is that, when writing standard inline()
code, end users are not responsible for reference counting at all.
Additionally, casting functions have been added and methods have
been overloaded so that conversions between python types and C
types are handled transparently for the basic types (char*,int,float,
double,std::string,std::complex<double>, etc.)
py::object has been augmented to handle attribute access, function
calling, method calling, and pretty much all of the rest of the
PyObject_xxx API.
This is near feature complete for weave 0.3. The remaining tasks are
to test on other platforms and re-write the documentation.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
py::object class' capabilities and unit tests to check them and
changes to test cases/examples to use the new features.
There is also one other BIG change. return_val has been changed
from a PyObject* to a py::object. This removes the need to handle
reference counting almost completely from inline() code. I am very
happy about this. :-)
All tests pass on win32, but the examples still need some work.
|
| |
|
|
|
|
|
| |
catch_all converters which convert the object to a py::object on the C++
side of things.
added more tests for attributes on new scxx classes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weave. This is needed so that people switching between compilers don't end
up trying to link c++ object files built with incompatible compilers together.
changed Py_INCREF to a Py_XINCREF to guard against NULL pointer problems
in convert_to_xxx routines.
lengthened the type_names strings for Numeric type names in
standard_array_spec. It was shorter than some of the names. yikes!
choose_compiler stuff is no longer done by ext_modules. This was used
to allow xxx_convterters and xxx_info objects to generate different code
depending on which compiler was used. This is no longer done, and I don't
think it should be necessary going forward. I've left a little of the code
in case I'm wrong, but will probably hack it out soon.
|
| |
|
|
|
|
| |
converters to PyObject*
converted testing to use scipy_test.testing
|
|
|
0.
The underlying library code is significantly re-factored and simpler. There used to be a xxx_spec.py and xxx_info.py file for every group of type conversion classes. The spec file held the python code that handled the conversion and the info file had most of the C code templates that were generated. This proved pretty confusing in practice, so the two files have mostly been merged into the spec file.
Also, there was quite a bit of code duplication running around. The re-factoring was able to trim the standard conversion code base (excluding blitz and accelerate stuff) by about 40%. This should be a huge maintainability and extensibility win.
1.
With multiple months of using Numeric arrays, I've found some of weave's "magic variable" names unwieldy and want to change them. The following are the old declarations for an array x of Float32 type:
PyArrayObject* x = convert_to_numpy(...);
float* x_data = (float*) x->data;
int* _Nx = x->dimensions;
int* _Sx = x->strides;
int _Dx = x->nd;
The new declaration looks like this:
PyArrayObject* x_array = convert_to_numpy(...);
float* x = (float*) x->data;
int* Nx = x->dimensions;
int* Sx = x->strides;
int Dx = x->nd;
This is obviously not backward compatible, and will break some code (including a lot of mine). It also makes inline() code more readable and natural to write.
2.
I've switched from CXX to Gordon McMillan's SCXX for list, tuples, and dictionaries. I like CXX pretty well, but its use of advanced C++ (templates, etc.) caused some portability problems. The SCXX library is similar to CXX but doesn't use templates at all. This, like (1) is not an
API compatible change and requires repairing existing code.
I have also thought about boost python, but it also makes heavy use of templates. Moving to SCXX gets rid of almost all template usage for the standard type converters which should help portability. std::complex and std::string from the STL are the only templates left. Of course blitz still uses templates in a major way so weave.blitz will continue to be hard on compilers.
I've actually considered scrapping the C++ classes for list, tuples, and
dictionaries, and just fall back to the standard Python C API because the classes are waaay slower than the raw API in many cases. They are also more convenient and less error prone in many cases, so I've decided to stick with them. The PyObject variable will always be made available for variable "x" under the name "py_x" for more speedy operations. You'll definitely want to use these for anything that needs to be speedy.
3.
strings are converted to std::string now. I found this to be the most useful type in for strings in my code. Py::String was used previously.
4.
There are a number of reference count "errors" in some of the less tested conversion codes such as instance, module, etc. I've cleaned most of these up. I put errors in quotes here because I'm actually not positive that objects passed into "inline" really need reference counting applied to them. The dictionaries passed in by inline() hold references to these objects so it doesn't seem that they could ever be garbage collected inadvertently. Variables used by ext_tools, though, definitely need the reference counting done. I don't think this is a major cost in speed, so it probably isn't worth getting rid of the ref count code.
5.
Unicode objects are now supported. This was necessary to support rendering Unicode strings in the freetype wrappers for Chaco.
6.
blitz++ was upgraded to the latest CVS. It compiles about twice as fast as the old blitz and looks like it supports a large number of compilers (though only gcc 2.95.3 is tested). Compile times now take about 9 seconds on my 850 MHz PIII laptop.
|
