1) Static members and static functions inside class can be accessed as ModuleName.ClassName.FunctionName (MemberName respectively). Old way aka ModuleName.ClassName_FunctionName still works.
2) Same goes for enums inside classes: ModuleName.ClassName.EnumValue1 etc.
3) More 'runme' tests for lua + modifications to existing tests to test new changes.
Code is loosely based upon python implemenation of the same thing.
Patch #62.
This fix makes the handling of type 'float' and 'double' the same. The implementation requires the
C99 isfinite() macro, or otherwise some platform dependent equivalents, to be available.
Add two helper functions to the Lua runtime, "SWIG_Lua_pusherrstring"
and "SWIG_Lua_pushferrstring".
These are like the standard Lua functions lua_pushstring and
lua_pushfstring respectively, except that the strings are prefixed
with the location of the innermost Lua call-point (as generated by
luaL_where).
Advantages:
- it avoids the swig user having to jump through hoops to get print to
work as expected when redefining repr/str slots.
- typing the name of a variable on the python prompt now prints the
result of a (possibly redefined) repr, without the swig user having to
do any extra work.
- when redefining repr, the swig user doesn't necessarily have to
redefine str as it will call the redefined repr
- the behaviour is exactly the same as without the -builtin option while
requiring no extra work by the user (aside from adding the
%feature("python:slot...) statements of course)
- the patch simplifies pyrun.swg a tiny bit.
Disadvantage:
- default str() will give different (but clearer?) output on swigged
classes compared to unpatched swig
SF Bug #326
%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
SF bug #1327
This doesn't have any noticeable effect with the usage of
SWIG_AsWCharPtrAndSize as shipped by SWIG, but could be a problem if a
user is using this function with cptr equal to zero and psize is non-zero
- the length would be incorrectly set due to the call to PyUnicode_GetSize
failing.
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
* New test case tests that %attribute macros correctly supports passing
template with multiple parameters as class name or attribute type name
* Some further changes were made to %attribute macros - now
AttributeType is protected with %arg as well. This allows you
to have attributes of type e.g. std::pair<int,int> etc
Update CHANGES file for %attribute template fixes
Closes#48
- once installed, Octave functions can never really be uninstalled
(clear -f doesn't prevent the function being called again), so
it makes no sense to install functions more than once
- this can lead to a significant speed-up of module loading times,
up to a factor of 10 for a large module loaded multiple times
- this introduces a memory leak, which becomes significant for large
modules (many global variables) and many module re-loadings (e.g.
during a long-running script)
- the original motivation was to prevent double-frees on exit, but this
problem appears to have been fixed by the _Exit() hack in later commits,
and in any case is an issue only for Octave ~3.2, so it should be safe to
remove; tested by running Octave examples/test suite with Debian 3.2.4 and
built-from-source 3.2.4, 3.4.3, and 3.6.3
On 19/04/13 18:41, Geert Janssens wrote:
> Hi,
>
> I'm working through the failing testcases for guile. One testcase fails
> with a compilation error in some generated code based on std_map and
> std_pair. I know exactly where this generated code comes from, but my
> C++ knowledge is insufficient to understand the error, let alone remedy
> it. I gather some kind of const violation, but that's all I can read
> from it :( My hope is that someone used to working with stl will more
> easily understand it.
>
> So, if someone can help me understand the error and what the fix would
> be in C++, I can fix the corresponding .i file.
>
> This is the code snippet the causes the error:
>
<snip>
>
> /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:88:12:
> error: non-static const member ‘const std::pair<int, A*> std::pair<int,
> const std::pair<int, A*> >::second’, can’t use default assignment operator
This is the main problem - it is saying there is no default assignment
operator (because one of the members in pair is const). The solution is
to avoid assignment. I've attached a patch to do this plus some error
message corrections.
William
All of guile's interface files now use the scm interface.
This should not affect any users. Swig generated code
using the scm interface can be mixed with gh interface
using user code.
It does simplify maintenance of the guile swig code though.
'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.
