* ahnolds-python34:
Python tp_allocs -> tp_next corrections
Cosmetic correction for Python tp_version -> tp_version_tag
Add -Wmissing-field-initializers to python Travis testing
Python 3.3 builtin missing field initializers added
Adding tp_finalize field to PyTypeObject for Python 3.4 and -builtin
Adding nb_matrix_multiply and nb_inplace_matrix_multiply fields to PyNumberMethods for Python version 3.5 and up
Adding tp_finalize field to PyTypeObject for Python version 3.4 and up
Hack to use the std::array support for boost::array.
Is limited as it currently exposes some 'using' bugs in SWIG.
For example, the type system fails to see that pointers to std::array
and pointers to boost::array are the same.
This approach saves having to maintain separate boost::array support.
The 'using' bug ought to be fixed, otherwise separate boost_array.i
files could be easily made from the std_array.i files.
Setting an STL container wrapper slice better matches the way Ruby
arrays work. The behaviour is now the same as Ruby arrays. The only
exception is the default value used when expanding a container
cannot be nil as this is not a valid type/value for C++ container
elements.
Access via ranges and slices now behave identically to Ruby arrays.
The fixes are mostly for out of range indices and lengths.
- Zero length slice requests return an empty container instead of nil.
- Slices which request a length greater than the size of the container
no longer chop off the last element.
- Ranges which used to return nil now return an empty array when the
the start element is a valid index.
Using negative indexes to set values works the same as Ruby arrays, eg
%template(IntVector) std::vector<int>;
iv = IntVector.new([1,2,3,4])
iv[-4] = 9 # => [1,2,3,9]
iv[-5] = 9 # => IndexError
These work much like any of the other STL containers except Python slicing
is somewhat limited because the array is a fixed size. Only slices of
the full size are supported.
Fix error when append on a SWIG Object with -builtin:
x.append(10)
SystemError: error return without exception set
Having append and next methods on a SWIG object by default doesn't seem
right to me though.
Fix %shared_ptr support for private and protected inheritance.
- Remove unnecessary Warning 520: Derived class 'Derived' of 'Base'
is not similarly marked as a smart pointer
- Do not generate code that attempts to cast up the inheritance chain in the
type system runtime in such cases as it doesn't compile and can't be used.
Remove unnecessary warning 520 for %shared_ptr when the base class is ignored.
* ruby-shared-ptr:
Add more Ruby shared_ptr runtime tests
Add RUBYFLAGS for Ruby testing
li_boost_shared_ptr tests cleanup
Ruby shared_ptr testing enhancements
Add shared_ptr Ruby runtime test
SWIG_Ruby_ConvertPtrAndOwn changes for smartptr feature
Fix Ruby smartptr feature for classes in a namespace
Turn on missing shared_ptr tests for Octave
Turn on Ruby shared_ptr testing
shared_ptr typemap error message fix for global variables
Add Ruby shared_ptr support
smartptr feature support - factor out common code
Add Ruby shared_ptr typemaps
Ruby ownership refactor ready for smart pointers
Ruby free function declaration change