Adds preprocessor checks to avoid defining functions that use long long if it isn't available
Effects the following languages: javascript, octave, perl, python, r, ruby, tcl
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
rb_obj_is_kind_of can no longer be used for type checking as the
smartptr feature type, eg shared_ptr<Derived> cannot be cast to
a smartptr of the base class, eg shared_ptr<Base>.
Previously Derived could be cast to Base as they were in an
inheritance chain and the call to rb_define_class_under() used
SWIGTYPE_p_Base->clientdata for all derived classes.
Now SWIG_TypeCheck is always used.
This is a patch to resolve SF bug 2034216 (Github issue #225)
The bug is that the tracking code uses a ruby hash and thus may
allocate objects (Bignum) while running the GC. This was tolerated in
1.8 but is invalid (raises an exception) in 1.9.
The patch uses a C hash (also used by ruby) instead.
Move to construct on first use idiom for singleton definition,
which prevents problems with singletons between ruby swig modules
in an environment with multiple modules on MacOS 10.9 with xcode 5.1.
Before this fix, data was being shared between modules which caused
a crash on shutdown of the ruby interpreter if more than one
module was loaded at a time.
- some of the %.clean rules in the test-suite Makefiles were using a single tab
as an empty rule, dangerous! I've replaced these with the safer '@exit 0'.
%template for a std::multimap generated uncompilable code unless a
%template for a std::map of the same template types was also coded up.
This patch is needed in conjunction with previous commit - 5f1fff1849Closes#64Closes#65
Affects Ruby versions prior to 1.9 using std::complex wrappers if just using std::complex
as an output type. Also fix the Complex helper functions external visibility (to static by default).
Closes#52
'rubycontainer_extended.swg' generates warnings:
Warning 322: Redundant redeclaration of 'map_bang',
Warning 322: previous declaration of 'map_bang'.
The fix is to remove a redundant call to swig_container_extend for
swig::GC_VALUE.
Thanks
========================================================
SF Bug#1292 - Runtime fixes for Proc changes in ruby-1.9 when using STL wrappers that override the default predicate, such as:
%template(Map) std::map<swig::LANGUAGE_OBJ, swig::LANGUAGE_OBJ, swig::BinaryPredicate<> >;
Fixes li_std_functors testcases for Ruby 1.9.
Also rb_respond_to return values have changed subtely in 1.9 and return should be treated as a flag instead of checking for Qtrue, see SF Bug #1159.
Also fix li_std_map, li_std_set silently failing - rb_protect behaviour seems to have changed when an exception is thrown, so code has been changed to use rb_rescue. A call to 'rb_set_errinfo(Qnil)' could have solved this after the rb_protect call, but it is only available in 1.9+ and Ruby API changes are not easily and transparently detectable.
