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.
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.
With this change, generated code for golang treats char* as a string but
treats signed char* and unsigned char* as normal pointers. This seems to
fit better with the expected behavior, as the latter are more often used
as non-string data.
Notably it now works for "unsigned char*" strings.
Add a test to check that it now works in Java and also showing that it already
worked for the other languages with support for this typemap.
* appveyor-check-test-suite:
Appveyor testing expanded
Fix array overrun in li_carrays testcase
Warning fixes in generated Python code for 64bit Visual C++ on Windows.
Warning fixes in generated C# code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
Warning fixes in generated Java code for 64bit Visual C++ on Windows.
Warning fixes for 64bit visual c++ on Windows
C# gc tests failure fix
Add a space between literal and string macro
Since Lua 5.3 the "%c" format character in lua_pushfstring will produce
the string "<\XXX>" (XXX being a decimal code sequence) when
given unprintable characters.
Use lua_pushlstring instead to reproduce the old behavior.
When passing a byte array from c++ to Java using the director feature, the generated jni code does not release a temporary byte array.
This is the typemap specified in Java.swg:
%typemap(directorin, descriptor="[B") (char *STRING, size_t LENGTH) {
jbyteArray jb = (jenv)->NewByteArray($2);
(jenv)->SetByteArrayRegion(jb, 0, $2, (jbyte *)$1);
$input = jb;
}
%typemap(directorargout) (char *STRING, size_t LENGTH)
%{(jenv)->GetByteArrayRegion($input, 0, $2, (jbyte *)$1); %}
Notice that the call to NewByteArray doesn't contain a symmetric release logic as the SetByteArrayRegion/GetByteArrayRegion does.
Closes#386
_swig_makegostring will no longer work in the Go 1.5 release.
Keep the existing code so that existing users with current versions of
Go will not break suddenly.
* amaeldoe-master:
Add python runtime test for dynamically added attributes
Attribute of SWIG wrapped classes instances were overwritten on __init__()
Fix SwigPyObject->dict memory leak
Make __dict__ accessible for Python builtin classes
When a SWIG classes instances is initialized, its internal dictionary was
reset to NULL, which result in the loss of any attribute that might have
been set for the instance.
Only initialize the internal dictionary on actual PyObject creation.
class Test(MySwigWrappedClass):
def __init__(self):
self.val = "Random Value"
MySwigWrappedClass.__init__(self)
p = Test()
print hasattr(p, "val") # Should return True, but used to return False
The following patch attempt to fix a memory leak happening when a
random class attribute is set. The internal instance dictionary is
created but never freed.
This fixes the problem for me, although I am not sure the patch
is correct.
<code>
p = MySWIGClass()
p.random_attribute = 0
</code>
Valgrind report:
==18267== 280 bytes in 1 blocks are definitely lost in loss record 1,372 of 1,780
==18267== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18267== by 0x3A90A885DC: PyObject_Malloc (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90B101A8: _PyObject_GC_Malloc (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90B102AC: _PyObject_GC_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90A80943: PyDict_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90A6E8FC: PyFrame_New (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE1A65: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE088E: PyEval_EvalFrameEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE21DC: PyEval_EvalCodeEx (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AE22E1: PyEval_EvalCode (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AFB71E: ??? (in /usr/lib64/libpython2.7.so.1.0)
==18267== by 0x3A90AFC8DD: PyRun_FileExFlags (in /usr/lib64/libpython2.7.so.1.0)
==18267==
