You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(11) |
Nov
(184) |
Dec
(182) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(224) |
Feb
(404) |
Mar
(244) |
Apr
(232) |
May
(162) |
Jun
(193) |
Jul
(174) |
Aug
(161) |
Sep
(170) |
Oct
(283) |
Nov
(310) |
Dec
(130) |
2007 |
Jan
(210) |
Feb
(129) |
Mar
(174) |
Apr
(246) |
May
(269) |
Jun
(212) |
Jul
(229) |
Aug
(202) |
Sep
(190) |
Oct
(194) |
Nov
(172) |
Dec
(128) |
2008 |
Jan
(343) |
Feb
(137) |
Mar
(186) |
Apr
(266) |
May
(156) |
Jun
(147) |
Jul
(140) |
Aug
(78) |
Sep
(128) |
Oct
(126) |
Nov
(100) |
Dec
(106) |
2009 |
Jan
(152) |
Feb
(165) |
Mar
(209) |
Apr
(166) |
May
(97) |
Jun
(152) |
Jul
(159) |
Aug
(196) |
Sep
(151) |
Oct
(107) |
Nov
(128) |
Dec
(64) |
2010 |
Jan
(105) |
Feb
(77) |
Mar
(129) |
Apr
(151) |
May
(126) |
Jun
(97) |
Jul
(86) |
Aug
(99) |
Sep
(64) |
Oct
(88) |
Nov
(59) |
Dec
(91) |
2011 |
Jan
(159) |
Feb
(111) |
Mar
(153) |
Apr
(114) |
May
(88) |
Jun
(201) |
Jul
(158) |
Aug
(124) |
Sep
(101) |
Oct
(149) |
Nov
(160) |
Dec
(68) |
2012 |
Jan
(74) |
Feb
(68) |
Mar
(121) |
Apr
(92) |
May
(172) |
Jun
(100) |
Jul
(85) |
Aug
(65) |
Sep
(74) |
Oct
(105) |
Nov
(76) |
Dec
(21) |
2013 |
Jan
(101) |
Feb
(57) |
Mar
(76) |
Apr
(35) |
May
(43) |
Jun
(50) |
Jul
(32) |
Aug
(50) |
Sep
(33) |
Oct
(58) |
Nov
(26) |
Dec
(49) |
2014 |
Jan
(46) |
Feb
(49) |
Mar
(54) |
Apr
(33) |
May
(46) |
Jun
(57) |
Jul
(34) |
Aug
(36) |
Sep
(69) |
Oct
(37) |
Nov
(27) |
Dec
(57) |
2015 |
Jan
(25) |
Feb
(52) |
Mar
(97) |
Apr
(41) |
May
(44) |
Jun
(36) |
Jul
(27) |
Aug
(33) |
Sep
(29) |
Oct
(45) |
Nov
(23) |
Dec
(23) |
2016 |
Jan
(6) |
Feb
(31) |
Mar
(17) |
Apr
(41) |
May
(31) |
Jun
(51) |
Jul
(20) |
Aug
(36) |
Sep
(69) |
Oct
(55) |
Nov
(29) |
Dec
(17) |
2017 |
Jan
(25) |
Feb
(22) |
Mar
(29) |
Apr
(18) |
May
(30) |
Jun
(13) |
Jul
(22) |
Aug
(12) |
Sep
(20) |
Oct
(60) |
Nov
(36) |
Dec
(20) |
2018 |
Jan
(16) |
Feb
(12) |
Mar
(25) |
Apr
(15) |
May
(32) |
Jun
(28) |
Jul
(8) |
Aug
(20) |
Sep
(6) |
Oct
(40) |
Nov
(18) |
Dec
(56) |
2019 |
Jan
(21) |
Feb
(9) |
Mar
(30) |
Apr
(44) |
May
(18) |
Jun
(17) |
Jul
(12) |
Aug
(14) |
Sep
(17) |
Oct
(12) |
Nov
(19) |
Dec
(13) |
2020 |
Jan
(6) |
Feb
(22) |
Mar
(6) |
Apr
(7) |
May
(3) |
Jun
(32) |
Jul
(35) |
Aug
(11) |
Sep
(22) |
Oct
(9) |
Nov
(9) |
Dec
(14) |
2021 |
Jan
(21) |
Feb
(1) |
Mar
(8) |
Apr
(6) |
May
(2) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(15) |
Oct
(18) |
Nov
(3) |
Dec
(18) |
2022 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
(8) |
May
(5) |
Jun
(6) |
Jul
(7) |
Aug
(5) |
Sep
(12) |
Oct
(9) |
Nov
(4) |
Dec
(3) |
2023 |
Jan
(2) |
Feb
(2) |
Mar
(5) |
Apr
(9) |
May
(8) |
Jun
(10) |
Jul
(1) |
Aug
(5) |
Sep
(1) |
Oct
(2) |
Nov
(6) |
Dec
(2) |
2024 |
Jan
(6) |
Feb
(6) |
Mar
(10) |
Apr
(6) |
May
(10) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Hrutwik S. <sat...@gm...> - 2023-06-29 10:30:39
|
Hi Swig Team, Hope you are doing well. Can You please suggest the ways to improve the swig generated java api code whose native code is in c++? I have tried with upgrading the swig version to 3.0.12 and also using flags like -O and - fastdispatch but there was no any improvement observed. Please suggest more ways to improve it as early as possible. Thanks in advance, Hrutwik. |
From: Hrutwik S. <hru...@gm...> - 2023-06-29 05:55:24
|
Hi Swig Team, Hope you are doing well. Currently I am working on a swig generated Java api whose native code is in c++.Firstly we were using Swig version 2.0.10, but now we want some improvement in performance of swig layer. For that we have upgraded the swig version to 4.1.1 and used optimization flags like -O, -fastdispatch. But by compiling with this flag also we didn't see any improvement in performance. So could you please suggest some ways to improve the performance? Please give some advice. Thanks in advance, Hrutwik. |
From: Hrutwik S. <hru...@gm...> - 2023-06-29 05:40:05
|
Hi, Good day from India, I am currently working on one API product of the company. This API is written in C++ language and there is Java wrapper on it. So, there is a SWIG layer in between JAVA and C++. In the beginning we were using Swig version 2.0.10. But now we want some improvement in the performance, for that we have upgraded the swig version to 4.1.1 and used some optimization flags like -O , -fastdispatch. But after compiling with these flags we have not observed any improvement in the performance. Can you suggest some ways to improve the performance and what else we can do for that? Please advise. Thanks in advance, Hrutwik. |
From: Turritopsis D. T. En M. <tdt...@gm...> - 2023-06-27 10:07:25
|
Subject: Question about SWIG Good day from Singapore, In what scenarios do I need to connect programs written in C and C++ with a variety of high-level programming languages? Please advise. Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com GIMP also stands for Government-Induced Medical Problems. |
From: Francois G. <fra...@gm...> - 2023-06-18 15:53:05
|
Sorry in advance if this kind of question was answered already; I have no idea for which feature to reach or what to search for in this mailing list. I want to make an update to the swig 3.0.9 extension for Forth (https://github.com/forthy42/swig/) (gforth in particular); it uses Swig only to output C files we then compile to produce Forth interface files that look like this : ``` \ ------===< functions >===------- c-function vkCreateInstance vkCreateInstance a a a -- n ( pCreateInfo pAllocator pInstance -- ) c-function vkDestroyInstance vkDestroyInstance a a -- void ( instance pAllocator -- ) c-function vkEnumeratePhysicalDevices vkEnumeratePhysicalDevices a a a -- n ( instance pPhysicalDeviceCount pPhysicalDevices -- ) ``` We use Swig to map the types in the C program to normalized identifiers for our libcc.fs file (https://github.com/forthy42/gforth/blob/master/libcc.fs) (in the example above, it transforms pointers into "a" and ints into "n"). As usual (?) in Swig, most structures are made into pointers before being passed to and from C functions (devs recently added a way to do so for structures returned by value). But my goal is to bind Raylib, which like many game libraries tries to remove memory management by returning simple structures (such as vectors of 2 or 3 coordinates) by value. For this, I need to be able to output things of the form "c(*{ n n *})" for structures with 2 ints. Would there be a practical way of converting types to this kind of string depending on their inner members? Thanks for your hard work, François Gallois |
From: Marc D. <mar...@gm...> - 2023-06-16 08:24:36
|
I have two modules which share a common class definition and therefore a required function pointer typedef: %module Module1 typedef void(*MyClassCallback)(MyClass&); class MyClass { public: MyClass(MyClassCallback initializer); }; %module Module2 %import "Module1.i" %callback("%s_cb"); void DoSomething(MyClass&); %nocallback; When I generate C# wrappers for both modules, each module contains the exact same wrapper class for the function pointer typedef: public class SWIGTYPE_p_f_r_MyClass__void { private global::System.Runtime.InteropServices.HandleRef swigCPtr; internal SWIGTYPE_p_f_r_MyClass__void(global::System.IntPtr cPtr, bool futureUse) { swigCPtr = new global::System.Runtime.InteropServices.HandleRef(this, cPtr); } protected SWIGTYPE_p_f_r_MyClass__void() { swigCPtr = new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero); } internal static global::System.Runtime.InteropServices.HandleRef getCPtr(SWIGTYPE_p_f_r_MyClass__void obj) { return (obj == null) ? new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero) : obj.swigCPtr; } internal static global::System.Runtime.InteropServices.HandleRef swigRelease(SWIGTYPE_p_f_r_MyClass__void obj) { return (obj == null) ? new global::System.Runtime.InteropServices.HandleRef(null, global::System.IntPtr.Zero) : obj.swigCPtr; } } Is this intended behaviour and, if yes, how can I produce valid code with no conflicting class definitions like this? Thanks in advance! Marc |
From: Julien M. <jul...@gm...> - 2023-06-14 11:58:08
|
Hello, Two years later and change I’m revisiting this because I had an increasing need for this. I have figured out a why to make it work with the fragments, thanks William. It’s probably not optimized (I think I could figure out a way to use swig::from or something), and reference counting might be off, but it appears to work. In case someone stumbles upon this question, here’s what I came up with: https://github.com/jmarrec/SwigTestBed/blob/42e56b27452225dc825c55f5ee7ba3c565855154/Model.i#L56-L134 #if defined SWIGPYTHON %fragment("JsonToDict","header", fragment="SWIG_FromCharPtrAndSize") { PyObject* SWIG_From_JsonValue(const Json::Value& value) { if (value.isBool()) { return value.asBool() ? Py_True : Py_False; } else if (value.isIntegral()) { return PyLong_FromLongLong(value.asInt64()); } else if (value.isNumeric()) { return PyFloat_FromDouble(value.asDouble()); } else if (value.isString()) { // return PyUnicode_FromString(value.asCString()); const auto str = value.asString(); return SWIG_FromCharPtrAndSize(str.data(), str.size()); } else if (value.isArray()) { PyObject* result = PyList_New(value.size()); Py_ssize_t idx = 0; for( const auto& arrayElement : value) { // TODO: this should do a recursive call to convert n (which is Json::Value) to a python type... auto val = SWIG_From_JsonValue(arrayElement); // PyList_Append(result, val); PyList_SetItem(result, idx++, val); } return result; } else if (value.isObject()) { PyObject* result = PyDict_New(); for( const auto& id : value.getMemberNames()) { // TODO: this should do a recursive call to convert *$1[id] (which is a Json::Value) to a python type... auto val = SWIG_From_JsonValue(value[id]); PyDict_SetItemString(result, id.c_str(), val); Py_DECREF(val); } return result; } return PyDict_New(); } } %typemap(out, fragment="JsonToDict") Json::Value { $result = SWIG_From_JsonValue($1); }#endif #if defined SWIGRUBY %fragment("JsonToDict","header", fragment="SWIG_FromCharPtrAndSize") { VALUE SWIG_From_JsonValue(const Json::Value& value) { if (value.isBool()) { return value.asBool() ? Qtrue : Qfalse; } else if (value.isIntegral()) { return INT2NUM(value.asInt64()); } else if (value.isNumeric()) { return DOUBLE2NUM(value.asDouble()); } else if (value.isString()) { const auto str = value.asString(); return SWIG_FromCharPtrAndSize(str.data(), str.size()); } else if (value.isArray()) { VALUE result = rb_ary_new2(value.size()); for( const auto& arrayElement : value) { rb_ary_push(result, SWIG_From_JsonValue(arrayElement)); } return result; } else if (value.isObject()) { VALUE result = rb_hash_new(); for( const auto& id : value.getMemberNames()) { rb_hash_aset(result, ID2SYM(rb_intern(id.data())), SWIG_From_JsonValue(value[id])); } return result; } return rb_hash_new(); } } %typemap(out, fragment="JsonToDict") Json::Value { $result = SWIG_From_JsonValue($1); }#endif Best, Julien — Julien Marrec, EBCP, BPI MFBA Owner at EffiBEM <http://www.effibem.com> T: +33 6 95 14 42 13 LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) | (fr <https://fr.linkedin.com/in/julienmarrec/fr>) : <http://www.linkedin.com/in/julienmarrec> Le mer. 10 mars 2021 à 00:26, William S Fulton <ws...@fu...> a écrit : > Hi Julien > > With regards to recursive calls, I suggest your typemap should be a one > liner which simply calls into a support function. The support function can > then recursively call itself. Have a look at fragments in the Typemaps > chapter, where your fragment would contain the support function and the > support function would only be generated once no matter how many times the > typemap is used. > > William > > > On Wed, 3 Mar 2021 at 15:02, Julien Marrec <jul...@gm...> > wrote: > >> Hello, >> >> First, has anyone wrapped jsoncpp >> <https://github.com/open-source-parsers/jsoncpp> in Swig? If I can avoid >> reinventing the wheel... >> >> Otherwise, I basically have a Json::Value toJSON() method in C++. >> >> I'd like to return a python dict instead (and a Hash in ruby...). So >> far, I've done a workaround by creating a std::string toJSONString() { >> return toJSON().toStyledString(); }, and using %pythoncode (and %init >> with rb_eval_string in ruby). It works (see at end of email if you're >> curious), but I'd like to try a typemap(argout) instead. All my attempts >> so far have miserably failed, probably because: >> >> 1. This is pretty much the first time I tried to do a typemap, and, >> 2. I have no clue how to do a recursive call to the typemap(argout) >> itself. >> >> Here is one of my attempts (I tried with Json::Value instead of Json::Value >> * too) >> >> #if defined SWIGPYTHON >> >> %typemap(argout) Json::Value * { >> >> if ($1->isIntegral()) { >> $result = PyLong_FromLongLong($1->asInt64()); >> } else if ($1->isNumeric()) { >> $result = PyFloat_FromDouble($1->asDouble()); >> } else if ($1->isString()) { >> $result = PyUnicode_FromString($->.asString()); >> } else if ($1->isArray()) { >> $result = PyList_New(); >> for( const auto& n : *$1) { >> // TODO: this should do a recursive call to convert n (which is Json::Value) to a python type... >> PyList_Append(n); >> } >> } else if ($1->isObject()) { >> $result = PyDict_New(); >> for( const auto& id : $1->getMemberNames()) { >> // TODO: this should do a recursive call to convert *$1[id] (which is a Json::Value) to a python type... >> PyDict_SetItemString($result, id.c_str(), *$1[id]); >> } >> } >> } >> #endif >> >> The documentation for Json::Value is at >> https://open-source-parsers.github.io/jsoncpp-docs/doxygen/class_json_1_1_value.html >> >> *If someone could nudge me in the right direction, that'd be much >> appreciated.* >> >> Thank you, >> >> Julien >> ------------------------------ >> >> For reference my current workaround: in epJSON.i: >> >> #if defined SWIGRUBY >> // This isn't super clean and there might be a better way with typemaps in SWIG rather than using a String in between, >> // but still helpful I think: we redefine toJSON that will return a native ruby hash. 'json' is part of ruby stdlib since at least ruby 2.5.5 >> %init %{ >> rb_eval_string("OpenStudio::EPJSON.module_eval { define_method(:toJSON) { |arg| json_str = self.toJSONString(arg); require 'json'; JSON.load(json_str); }; module_function(:toJSON) }"); >> %} >> #endif >> >> #if defined SWIGPYTHON >> >> // Let's use monkey-patching via unbound functions >> // Edit: not even needed here >> %pythoncode %{ >> # Manually added: Lazy-load the json module (python std lib) and return a dict via toJSONString >> def toJSON(*args) -> dict: >> import json >> return json.loads(toJSONString(*args)) >> %} >> #endif >> >> >> -- >> Julien Marrec, EBCP, BPI MFBA >> Owner at EffiBEM <http://www.effibem.com> >> T: +33 6 95 14 42 13 >> >> LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr >> <https://fr.linkedin.com/in/julienmarrec/fr>) : >> <http://www.linkedin.com/in/julienmarrec> >> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user >> > |
From: William S F. <ws...@fu...> - 2023-06-01 10:52:41
|
$ c++filt _ZdlPvj operator delete(void*, unsigned int) To me you have some sort of compiler setup/installation issue. Best to consult some c++ forums. William On Sun, 21 May 2023 at 09:55, Patrick Good <pat...@os...> wrote: > Hello > > > I use swig with python. > The environment I use is PetaLinux/Yocto to build the project. Currently > the project is just a small test code to try to run it to test the > interface. SWIG version is 4.1.1, Python version is: 3.9.9. > > *Error:* > > root@mz7010-som-base-2022-1:~# python3 > Python 3.9.9 (main, Nov 15 2021, 18:05:17) > [GCC 11.2.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import Sytemtechnik.libsysproject > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ModuleNotFoundError: No module named 'Sytemtechnik' > >>> import Systemtechnik.libsysproject > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/usr/lib/python3.9/Systemtechnik/libsysproject.py", line 10, in > <module> > from . import _libsysproject > ImportError: /usr/lib/python3.9/Systemtechnik/_libsysproject.so: undefined > symbol: _ZdlPvj > > > *Makefile:* > > APP = libsysproject > > LIBSOURCES=*.cpp > > OUTS = *.o > > NAME := sysproject > > MAJOR = 1.0 > > MINOR = 1 > > VERSION = $(MAJOR).$(MINOR) > > all: lib$(NAME).so > > lib$(NAME).so.$(VERSION): compile > > # $(CC) $(LDFLAGS) $(OUTS) -shared -Wl,-soname,_lib$(NAME).so.$(MAJOR) -o > _lib$(NAME).so.$(VERSION) > > $(CC) libsysproject.o libsysproject_wrap.o -shared -o _lib$(NAME).so > > lib$(NAME).so: lib$(NAME).so.$(VERSION) > > #rm -f _lib$(NAME).so.$(MAJOR) _lib$(NAME).so > > #ln -s _lib$(NAME).so.$(VERSION) _lib$(NAME).so.$(MAJOR) > > #ln -s _lib$(NAME).so.$(MAJOR) _lib$(NAME).so > > compile: swig > > # $(CC) $(CFLAGS) -c -fPIC libsysproject.cpp libsysproject_wrap.cxx > -Irecipe-sysroot/usr/include/python3.9 > > $(CC) -c -fPIC libsysproject.cpp libsysproject_wrap.cxx > -Irecipe-sysroot/usr/include/python3.9 > > swig: > > # /usr/local/bin/swig -c++ -python -py3 libsysproject.i > > /usr/local/bin/swig -c++ -python libsysproject.i > > clean: > > rm -rf *.o *.so *.so.* > > > *cpp file:* > > #include "include/libsysproject.hpp" > > Example::Example() {} > > Example::~Example() {} > > int Example::addNumbers(int a, int b) { > > return a + b; > > } > > > > *hpp file:* > > #ifndef LIBSYSPROJECT_HPP_ > > #define LIBSYSPROJECT_HPP_ > > #include <stdint.h> > > #include <sys/types.h> > > class Example { > > public: > > Example(); > > ~Example(); > > int addNumbers(int a, int b); > > }; > > #endif // LIBSYSPROJECT_HPP_ > > *.i file:* > > %module libsysproject > > %{ > > #include "include/libsysproject.hpp" > > %} > > %include "include/libsysproject.hpp" > > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: William S F. <ws...@fu...> - 2023-06-01 10:25:16
|
That version check was for syntax checking, but we removed all the Python 3 only syntax so now the .py file can work with both Python 2.7 and 3.3 and later. Take a look at %begin to put in a similar version check. William On Wed, 24 May 2023 at 12:30, Julien Marrec <jul...@gm...> wrote: > https://www.swig.org/ > > *SWIG-4.1.0 summary:* > > - Python 3.3 is now the oldest Python 3 version SWIG supports. > > Probably why? > -- > Julien Marrec, EBCP, BPI MFBA > Owner at EffiBEM <http://www.effibem.com> > T: +33 6 95 14 42 13 > > LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr > <https://fr.linkedin.com/in/julienmarrec/fr>) : > <http://www.linkedin.com/in/julienmarrec> > > > Le mer. 24 mai 2023 à 11:49, Lluís Alemany Puig < > llu...@up...> a écrit : > >> Hello >> >> I just noticed that swig 4.0.2 includes a check of python's version at >> the beginning of every script, like so: >> >> # This file was automatically generated by SWIG (http://www.swig.org). >> # Version 4.0.2 >> # >> # Do not make changes to this file unless you know what you are >> doing--modify >> # the SWIG interface file instead. >> >> from sys import version_info as _swig_python_version_info >> if _swig_python_version_info < (2, 7, 0): >> raise RuntimeError("Python 2.7 or later required") >> >> # Import the low-level C/C++ module >> >> However, swig 4.1.1 no longer does it: >> >> # This file was automatically generated by SWIG (https://www.swig.org). >> # Version 4.1.1 >> # >> # Do not make changes to this file unless you know what you are doing - >> modify >> # the SWIG interface file instead. >> >> from sys import version_info as _swig_python_version_info >> # Import the low-level C/C++ module >> >> Is this a bug, or was this removed on purpose? >> >> Thanks a lot, >> >> Lluís. >> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user >> > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: Julien M. <jul...@gm...> - 2023-05-24 11:29:39
|
https://www.swig.org/ *SWIG-4.1.0 summary:* - Python 3.3 is now the oldest Python 3 version SWIG supports. Probably why? -- Julien Marrec, EBCP, BPI MFBA Owner at EffiBEM <http://www.effibem.com> T: +33 6 95 14 42 13 LinkedIn (en <https://www.linkedin.com/in/julienmarrec>) *| *(fr <https://fr.linkedin.com/in/julienmarrec/fr>) : <http://www.linkedin.com/in/julienmarrec> Le mer. 24 mai 2023 à 11:49, Lluís Alemany Puig <llu...@up...> a écrit : > Hello > > I just noticed that swig 4.0.2 includes a check of python's version at the > beginning of every script, like so: > > # This file was automatically generated by SWIG (http://www.swig.org). > # Version 4.0.2 > # > # Do not make changes to this file unless you know what you are > doing--modify > # the SWIG interface file instead. > > from sys import version_info as _swig_python_version_info > if _swig_python_version_info < (2, 7, 0): > raise RuntimeError("Python 2.7 or later required") > > # Import the low-level C/C++ module > > However, swig 4.1.1 no longer does it: > > # This file was automatically generated by SWIG (https://www.swig.org). > # Version 4.1.1 > # > # Do not make changes to this file unless you know what you are doing - > modify > # the SWIG interface file instead. > > from sys import version_info as _swig_python_version_info > # Import the low-level C/C++ module > > Is this a bug, or was this removed on purpose? > > Thanks a lot, > > Lluís. > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: Lluís A. P. <llu...@up...> - 2023-05-24 09:48:31
|
Hello I just noticed that swig 4.0.2 includes a check of python's version at the beginning of every script, like so: # This file was automatically generated by SWIG (http://www.swig.org). # Version 4.0.2 # # Do not make changes to this file unless you know what you are doing--modify # the SWIG interface file instead. from sys import version_info as _swig_python_version_info if _swig_python_version_info < (2, 7, 0): raise RuntimeError("Python 2.7 or later required") # Import the low-level C/C++ module However, swig 4.1.1 no longer does it: # This file was automatically generated by SWIG (https://www.swig.org). # Version 4.1.1 # # Do not make changes to this file unless you know what you are doing - modify # the SWIG interface file instead. from sys import version_info as _swig_python_version_info # Import the low-level C/C++ module Is this a bug, or was this removed on purpose? Thanks a lot, Lluís. |
From: Patrick G. <pat...@os...> - 2023-05-21 08:55:16
|
Hello I use swig with python. The environment I use is PetaLinux/Yocto to build the project. Currently the project is just a small test code to try to run it to test the interface. SWIG version is 4.1.1, Python version is: 3.9.9. Error: root@mz7010-som-base-2022-1:~# python3 Python 3.9.9 (main, Nov 15 2021, 18:05:17) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import Sytemtechnik.libsysproject Traceback (most recent call last): File "<stdin>", line 1, in <module> ModuleNotFoundError: No module named 'Sytemtechnik' >>> import Systemtechnik.libsysproject Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.9/Systemtechnik/libsysproject.py", line 10, in <module> from . import _libsysproject ImportError: /usr/lib/python3.9/Systemtechnik/_libsysproject.so: undefined symbol: _ZdlPvj Makefile: APP = libsysproject LIBSOURCES=*.cpp OUTS = *.o NAME := sysproject MAJOR = 1.0 MINOR = 1 VERSION = $(MAJOR).$(MINOR) all: lib$(NAME).so lib$(NAME).so.$(VERSION): compile # $(CC) $(LDFLAGS) $(OUTS) -shared -Wl,-soname,_lib$(NAME).so.$(MAJOR) -o _lib$(NAME).so.$(VERSION) $(CC) libsysproject.o libsysproject_wrap.o -shared -o _lib$(NAME).so lib$(NAME).so: lib$(NAME).so.$(VERSION) #rm -f _lib$(NAME).so.$(MAJOR) _lib$(NAME).so #ln -s _lib$(NAME).so.$(VERSION) _lib$(NAME).so.$(MAJOR) #ln -s _lib$(NAME).so.$(MAJOR) _lib$(NAME).so compile: swig # $(CC) $(CFLAGS) -c -fPIC libsysproject.cpp libsysproject_wrap.cxx -Irecipe-sysroot/usr/include/python3.9 $(CC) -c -fPIC libsysproject.cpp libsysproject_wrap.cxx -Irecipe-sysroot/usr/include/python3.9 swig: # /usr/local/bin/swig -c++ -python -py3 libsysproject.i /usr/local/bin/swig -c++ -python libsysproject.i clean: rm -rf *.o *.so *.so.* cpp file: #include "include/libsysproject.hpp" Example::Example() {} Example::~Example() {} int Example::addNumbers(int a, int b) { return a + b; } hpp file: #ifndef LIBSYSPROJECT_HPP_ #define LIBSYSPROJECT_HPP_ #include <stdint.h> #include <sys/types.h> class Example { public: Example(); ~Example(); int addNumbers(int a, int b); }; #endif // LIBSYSPROJECT_HPP_ .i file: %module libsysproject %{ #include "include/libsysproject.hpp" %} %include "include/libsysproject.hpp" |
From: William S F. <ws...@fu...> - 2023-05-19 07:22:08
|
I suggest writing a custom out typemap for your error code type (int ???) and stop using %exception. Something along the lines of %typemap(out,noblock=1,fragment="SWIG_From_int") int { if ($1 == 0) { // $result = SWIG_From_int((int)($1)); // This is the default typemap for int $result = SWIG_Py_Void(); } else { PyErr_SetString(PyExc_RuntimeError, "an error has occurred"); // will replace with something more descriptive SWIG_fail; } } which returns None (void) on success otherwise throws an exception. William On Fri, 5 May 2023 at 23:07, Montare, Aidan A. (Fed) via Swig-user < swi...@li...> wrote: > Hi! I’m wrapping a library where most of the functions follow the > convention of returning an error code or 0 if no error. I’ve followed swig > instructions to write an exception handler: > > > > %exception { > > $action > > if (result != 0) { > > PyErr_SetString(PyExc_RuntimeError, "an error has occurred"); // > will replace with something more descriptive > > SWIG_fail; > > } > > } > > > > Since errors are now translated into python exceptions, I think if the > function does succeed, I’d like to not return the error code 0. Many of the > functions return via a parameter, and I think writing > > > > result = foo(arg) > > > > would be cleaner than having to write > > > > _, result = foo(arg) > > > > all over the place. > > > > How can I tell swig that the error code should not be return the error > code? > > > > Best wishes, > > > > Aidan Montare (she/her) > > Time Realization and Distribution Group > > Time and Frequency Division > > NIST Boulder > > > > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: Montare, A. A. (Fed) <aid...@ni...> - 2023-05-05 22:07:10
|
Hi! I'm wrapping a library where most of the functions follow the convention of returning an error code or 0 if no error. I've followed swig instructions to write an exception handler: %exception { $action if (result != 0) { PyErr_SetString(PyExc_RuntimeError, "an error has occurred"); // will replace with something more descriptive SWIG_fail; } } Since errors are now translated into python exceptions, I think if the function does succeed, I'd like to not return the error code 0. Many of the functions return via a parameter, and I think writing result = foo(arg) would be cleaner than having to write _, result = foo(arg) all over the place. How can I tell swig that the error code should not be return the error code? Best wishes, Aidan Montare (she/her) Time Realization and Distribution Group Time and Frequency Division NIST Boulder |
From: Montare, A. A. (Fed) <aid...@ni...> - 2023-05-05 20:46:04
|
Thanks for the suggestion! I'll give this a try when I get back to implementing that part of the library. Best wishes, Aidan Montare (she/her) Time Realization and Distribution Group Time and Frequency Division NIST Boulder From: William S Fulton <ws...@fu...> Sent: Friday, April 28, 2023 11:02 AM To: Montare, Aidan A. (Fed) <aid...@ni...> Cc: swi...@li... Subject: Re: [Swig-user] generated wrapper code contains errors in arrays of dimension > 2 Hi Aidan You need to write a typemap for this. Copy and modify the SWIGTYPE[ANY][ANY] typemaps for what you want. Editing code by hand is never ideal. Alternative workaround is to ignore the variable with %ignore and add in some C getters/setters which will wrap using default typemaps: %inline %{ void setX(int i, int j, int k, double val) { X[i][j][k] = val; } void getX(int i, int j, int k) { return X[i][j][k]; } %} William On Thu, 27 Apr 2023 at 20:11, Montare, Aidan A. (Fed) via Swig-user <swi...@li...<mailto:swi...@li...>> wrote: Hi, I'm a new user of SWIG, and ran across an issue that seems to have be documented before: https://github.com/swig/swig/issues/142 (from that thread:) """Array with more than two dimensions, e.g. extern double x[2][3][4]; lead to wrapped code with compile errors: swig_wrap.c: In function '_wrap_x_set': swig_wrap.c:2425:50: error: incompatible types when assigning to type 'double[4]' from type 'double' for (; jj < (size_t)3; ++jj) x[ii][jj] = inp[ii][jj]; ^ """ I was just wondering if anyone has found workarounds for this issue, or if there has been any progress on it since that issue was last commented on. At the moment, since I only have one single case of this in the library I'm trying to wrap, I'm considering modifying the generated wrappers by hand. I'd be interested in submitting a pull request to SWIG if I were able to fix the issue more generally, but I don't think I'm experienced enough to be able to do that yet. Best wishes, Aidan Montare (she/her) Time Realization and Distribution Group Time and Frequency Division NIST Boulder _______________________________________________ Swig-user mailing list Swi...@li...<mailto:Swi...@li...> https://lists.sourceforge.net/lists/listinfo/swig-user |
From: Robert H. <he...@de...> - 2023-05-02 19:46:56
|
At Tue, 2 May 2023 12:20:31 -0700 Rob McDonald <rob...@gm...> wrote: > > I have a C++ application wrapped with Swig to Python. > > Some of my users are seeing large and steady memory growth for extended > scripts that make repeated calls to the C++ side of things. > > The non-Swig version of my program also has an embedded scripting > language. If I recreate their Python calls with my scripting language, I > do not see the memory growth. Therefore, I do not initially think the > memory leaks are inherent to my C++ code. > > How can I go about tracking memory use (between a wrapped C++ API, Swig > middle-layer, and Python) from Python? What sorts of diagnostic tools are > there for this? Is your wrapper passing non-scaler objects back and forth between C++ and Python (eg converting things like vectors to lists or lists to vectors, that sort of thing)? If you are you should check to be sure you are including typemaps to "free" and temporary storage being used (freearg typemaps). Also, if your wrappers are wrapping C++ constructors (directly or indirectly), make sure you are also wrapping the destructors. Note: you will probably have to *explicitly* call the destructors -- this might mean that the Python code needs to call a wrapper that includes a call to operator delete() (to match the call to operator new()). You probably won't be getting "free" mamory management when temporary objects go out of scope (like they would in a pure C++ or pure Python program). > > I know that I can not run my C++ with Address Sanitizer or Valgrind under > Python without re-compiling Python with these things enabled (I would > really like to avoid compiling Python). > > Thanks for any suggestions, > > Rob > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > > -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services he...@de... -- Webhosting Services |
From: Rob M. <rob...@gm...> - 2023-05-02 19:20:51
|
I have a C++ application wrapped with Swig to Python. Some of my users are seeing large and steady memory growth for extended scripts that make repeated calls to the C++ side of things. The non-Swig version of my program also has an embedded scripting language. If I recreate their Python calls with my scripting language, I do not see the memory growth. Therefore, I do not initially think the memory leaks are inherent to my C++ code. How can I go about tracking memory use (between a wrapped C++ API, Swig middle-layer, and Python) from Python? What sorts of diagnostic tools are there for this? I know that I can not run my C++ with Address Sanitizer or Valgrind under Python without re-compiling Python with these things enabled (I would really like to avoid compiling Python). Thanks for any suggestions, Rob |
From: prajjwal p. <pra...@gm...> - 2023-04-28 18:02:37
|
Hi William, Thank you for the suggestions. Yes, I was actually using the %exception directive before. The reason I am not able to use it is that it only encloses the function call that is being wrapped and leaves other parts (such as creation of new object on heap before it is returned) outside. This leads to race conditions in C# as calls to constructors are not thread safe. I will look into the "valuewrapper" feature. Best regards, Prajjwal On Fri, Apr 28, 2023 at 10:57 AM William S Fulton <ws...@fu...> wrote: > Hi Prajjwal > > Have you looked at %exception as that allows you to put code just before > and > after the call to the wrapped function. The result variable is defined > before > the wrapped function is called. > > I'm not entirely sure if this will help, but if you use SwigValueWrapper > via the "valuewrapper" feature it is a useful trick to remove the default > instantiation of the result variable. > > William > > On Tue, 25 Apr 2023 at 17:15, prajjwal prem <pra...@gm...> > wrote: > >> Hi Jim, >> >> Thanks for the solution. The typemap(ret) works perfectly for injecting >> the code at the end. But using typemap(check) does not include the >> declaration of the result variable. The c++ default constructor for result >> needs to be inside the injected mutex code. I tried using the optimal flag >> in typemap(out) but exception handling code overrides that behavior. >> >> Is there a way to tell swig that declaration of the result variable >> should be after the typemap(check)? >> >> Once again thanks for the solution above. >> >> On Mon, Apr 24, 2023 at 8:30 PM Jim <guy...@12...> wrote: >> >>> >>> Hi Prajjwal, >>> You can try this : >>> >>> %typemap(ret) SWIGTYPE { >>> //inject-1 >>> } >>> >>> %typemap(ret) SWIGTYPE & { >>> //inject-2 >>> } >>> >>> %typemap(ret) SWIGTYPE * { >>> //inject-3 >>> } >>> >>> %typemap(check) SWIGTYPE * { >>> //inject-4 >>> } >>> >>> %typemap(check) SWIGTYPE { >>> //inject-5 >>> } >>> >>> Note: keyword *SWIGTYPE* math any type(eg int\long\bool\T)。*SWIGTYPE &* >>> match any reference type (eg. int & \ long & \ bool& \ T&)。 You can add >>> different typemap according to your function type as needed。 >>> >>> >>> >>> >>> At 2023-04-25 05:27:05, "prajjwal prem" <pra...@gm...> wrote: >>> >>> Hi All, >>> >>> How to inject code at the top and bottom of each method generated in cpp >>> wrap file by SWIG? >>> >>> For Example: >>> >>> SWIGEXPORT int SWIGSTDCALL CSharp_swig_generated_method___(void *jarg1) >>> >>> { >>> >>> int jresult; //SWIG generated >>> >>> >>> >>> *// inject code here like mutex begin* >>> >>> >>> >>> /* >>> >>> SWIG generated code >>> >>> */ >>> >>> >>> >>> jresult = result; >>> >>> >>> >>> *// inject code here like mutex end* >>> >>> >>> >>> return jresult; >>> >>> } >>> >>> >>> Best regards, >>> >>> Prajjwal >>> >>> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user >> > |
From: William S F. <ws...@fu...> - 2023-04-28 17:22:31
|
Hi Prajjwal Have you looked at %exception as that allows you to put code just before and after the call to the wrapped function. The result variable is defined before the wrapped function is called. I'm not entirely sure if this will help, but if you use SwigValueWrapper via the "valuewrapper" feature it is a useful trick to remove the default instantiation of the result variable. William On Tue, 25 Apr 2023 at 17:15, prajjwal prem <pra...@gm...> wrote: > Hi Jim, > > Thanks for the solution. The typemap(ret) works perfectly for injecting > the code at the end. But using typemap(check) does not include the > declaration of the result variable. The c++ default constructor for result > needs to be inside the injected mutex code. I tried using the optimal flag > in typemap(out) but exception handling code overrides that behavior. > > Is there a way to tell swig that declaration of the result variable should > be after the typemap(check)? > > Once again thanks for the solution above. > > On Mon, Apr 24, 2023 at 8:30 PM Jim <guy...@12...> wrote: > >> >> Hi Prajjwal, >> You can try this : >> >> %typemap(ret) SWIGTYPE { >> //inject-1 >> } >> >> %typemap(ret) SWIGTYPE & { >> //inject-2 >> } >> >> %typemap(ret) SWIGTYPE * { >> //inject-3 >> } >> >> %typemap(check) SWIGTYPE * { >> //inject-4 >> } >> >> %typemap(check) SWIGTYPE { >> //inject-5 >> } >> >> Note: keyword *SWIGTYPE* math any type(eg int\long\bool\T)。*SWIGTYPE &* >> match any reference type (eg. int & \ long & \ bool& \ T&)。 You can add >> different typemap according to your function type as needed。 >> >> >> >> >> At 2023-04-25 05:27:05, "prajjwal prem" <pra...@gm...> wrote: >> >> Hi All, >> >> How to inject code at the top and bottom of each method generated in cpp >> wrap file by SWIG? >> >> For Example: >> >> SWIGEXPORT int SWIGSTDCALL CSharp_swig_generated_method___(void *jarg1) >> >> { >> >> int jresult; //SWIG generated >> >> >> >> *// inject code here like mutex begin* >> >> >> >> /* >> >> SWIG generated code >> >> */ >> >> >> >> jresult = result; >> >> >> >> *// inject code here like mutex end* >> >> >> >> return jresult; >> >> } >> >> >> Best regards, >> >> Prajjwal >> >> _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: William S F. <ws...@fu...> - 2023-04-28 17:02:42
|
Hi Aidan You need to write a typemap for this. Copy and modify the SWIGTYPE[ANY][ANY] typemaps for what you want. Editing code by hand is never ideal. Alternative workaround is to ignore the variable with %ignore and add in some C getters/setters which will wrap using default typemaps: %inline %{ void setX(int i, int j, int k, double val) { X[i][j][k] = val; } void getX(int i, int j, int k) { return X[i][j][k]; } %} William On Thu, 27 Apr 2023 at 20:11, Montare, Aidan A. (Fed) via Swig-user < swi...@li...> wrote: > Hi, I’m a new user of SWIG, and ran across an issue that seems to have be > documented before: > > > > https://github.com/swig/swig/issues/142 > > > > > > (from that thread:) > > > > ““”Array with more than two dimensions, e.g. extern double x[2][3][4]; > lead to wrapped code with compile errors: > > swig_wrap.c: In function ‘_wrap_x_set’: > > swig_wrap.c:2425:50: error: incompatible types when assigning to type > ‘double[4]’ from type ‘double’ > > for (; jj < (size_t)3; ++jj) x[ii][jj] = inp[ii][jj]; > > ^ > > “”” > > > > > > I was just wondering if anyone has found workarounds for this issue, or if > there has been any progress on it since that issue was last commented on. > > > > At the moment, since I only have one single case of this in the library > I’m trying to wrap, I’m considering modifying the generated wrappers by > hand. I’d be interested in submitting a pull request to SWIG if I were able > to fix the issue more generally, but I don’t think I’m experienced enough > to be able to do that yet. > > > > Best wishes, > > > > Aidan Montare (she/her) > > Time Realization and Distribution Group > > Time and Frequency Division > > NIST Boulder > > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: William S F. <ws...@fu...> - 2023-04-28 07:34:34
|
I would run swig with the -E option using this input interface file: %module example %include <std_string.i> This will output the preprocessed code with the std::string typemaps at the end of the output. I advise this as the input files are full of macros and may be hard to follow. I'd copy the std::string typemaps and tweak for QString. The typemaps for std::string are comprehensive, you may only need a get away with just the in, out, typecheck typemaps for simple usage. Typemaps for QT types ought to go into a specific QT SWIG specific repository, please take a look at https://github.com/swig/swig/issues/88. William On Tue, 11 Apr 2023 at 12:55, Stefano Crocco <ste...@gm...> wrote: > Hello to everyone, > I'm new to SWIG and I'm trying to use SWIG to use the Qt C++ libraries [1] > from Ruby. After some simple tests, I tried to wrap some functions using > strings. Unfortunately, Qt doesn't use std::string to represent strings, > but > its own class, called QString. I'd like to be able to automatically > convert > QString to and from ruby String, just as the typemaps in std_string.i does > for > std::string. > > I hoped that, since QString can be converted to std::string and vice > versa, it > would be possible to somehow make use of the std_string.i library to tell > SWIG: > - when, converting from C++ to ruby, you find a QString, call the > QString::toStdString method to convert it to std::string, then apply the > default typemap for std::string > - when, converting from ruby to C++, you find String, convert it to a > std::string using the default typemap for std::string, then call > QString::fromStdString on the result. > > Unfortunately, as far as I can tell, this isn't possible. I hoped that > typemaps would be applied recursively, so I tried the following: > > %typemap(out) QString { > $result = $1.toStdString(); > } > > I hoped that SWIG would then notice that the resulting value wasn't a ruby > object but it still was a C++ class it knows how to convert to ruby. Of > course, that didn't work and I got the error: > error: cannot convert ‘std::string’ {aka > ‘std::__cxx11::basic_string<char>’} > to ‘VALUE’ {aka ‘long unsigned int’} in assignment > > Is there some way to converting QString to and from ruby String using, > directly or indirectly, the existing conversions of std::string? I'd like > to > avoid having to avoid writing the low-level conversion code myself, unless > absolutely necessary. I searched both the documentation and Google and > looked > at the code in std_string.i, but I couldn't find anything useful, so I > guess > it's not possible, but I'd like to be sure. > > Thanks in advance > > Stefano > > > [1] https://www.qt.io/ > > > > > _______________________________________________ > Swig-user mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user > |
From: Montare, A. A. (Fed) <aid...@ni...> - 2023-04-27 19:10:48
|
Hi, I'm a new user of SWIG, and ran across an issue that seems to have be documented before: https://github.com/swig/swig/issues/142 (from that thread:) """Array with more than two dimensions, e.g. extern double x[2][3][4]; lead to wrapped code with compile errors: swig_wrap.c: In function '_wrap_x_set': swig_wrap.c:2425:50: error: incompatible types when assigning to type 'double[4]' from type 'double' for (; jj < (size_t)3; ++jj) x[ii][jj] = inp[ii][jj]; ^ """ I was just wondering if anyone has found workarounds for this issue, or if there has been any progress on it since that issue was last commented on. At the moment, since I only have one single case of this in the library I'm trying to wrap, I'm considering modifying the generated wrappers by hand. I'd be interested in submitting a pull request to SWIG if I were able to fix the issue more generally, but I don't think I'm experienced enough to be able to do that yet. Best wishes, Aidan Montare (she/her) Time Realization and Distribution Group Time and Frequency Division NIST Boulder |
From: prajjwal p. <pra...@gm...> - 2023-04-25 16:14:55
|
Hi Jim, Thanks for the solution. The typemap(ret) works perfectly for injecting the code at the end. But using typemap(check) does not include the declaration of the result variable. The c++ default constructor for result needs to be inside the injected mutex code. I tried using the optimal flag in typemap(out) but exception handling code overrides that behavior. Is there a way to tell swig that declaration of the result variable should be after the typemap(check)? Once again thanks for the solution above. On Mon, Apr 24, 2023 at 8:30 PM Jim <guy...@12...> wrote: > > Hi Prajjwal, > You can try this : > > %typemap(ret) SWIGTYPE { > //inject-1 > } > > %typemap(ret) SWIGTYPE & { > //inject-2 > } > > %typemap(ret) SWIGTYPE * { > //inject-3 > } > > %typemap(check) SWIGTYPE * { > //inject-4 > } > > %typemap(check) SWIGTYPE { > //inject-5 > } > > Note: keyword *SWIGTYPE* math any type(eg int\long\bool\T)。*SWIGTYPE &* > match any reference type (eg. int & \ long & \ bool& \ T&)。 You can add > different typemap according to your function type as needed。 > > > > > At 2023-04-25 05:27:05, "prajjwal prem" <pra...@gm...> wrote: > > Hi All, > > How to inject code at the top and bottom of each method generated in cpp > wrap file by SWIG? > > For Example: > > SWIGEXPORT int SWIGSTDCALL CSharp_swig_generated_method___(void *jarg1) > > { > > int jresult; //SWIG generated > > > > *// inject code here like mutex begin* > > > > /* > > SWIG generated code > > */ > > > > jresult = result; > > > > *// inject code here like mutex end* > > > > return jresult; > > } > > > Best regards, > > Prajjwal > > |
From: Jim <guy...@12...> - 2023-04-25 02:45:27
|
Hi Prajjwal, You can try this : %typemap(ret) SWIGTYPE { //inject-1 } %typemap(ret) SWIGTYPE & { //inject-2 } %typemap(ret) SWIGTYPE * { //inject-3 } %typemap(check) SWIGTYPE * { //inject-4 } %typemap(check) SWIGTYPE { //inject-5 } Note: keyword SWIGTYPE math any type(eg int\long\bool\T)。SWIGTYPE & match any reference type (eg. int & \ long & \ bool& \ T&)。 You can add different typemap according to your function type as needed。 At 2023-04-25 05:27:05, "prajjwal prem" <pra...@gm...> wrote: Hi All, How to inject code at the top and bottom of each method generated in cpp wrap file by SWIG? For Example: SWIGEXPORT int SWIGSTDCALL CSharp_swig_generated_method___(void *jarg1) { int jresult; //SWIG generated // inject code here like mutex begin /* SWIG generated code */ jresult = result; // inject code here like mutex end return jresult; } Best regards, Prajjwal |
From: prajjwal p. <pra...@gm...> - 2023-04-24 21:27:53
|
Hi All, How to inject code at the top and bottom of each method generated in cpp wrap file by SWIG? For Example: SWIGEXPORT int SWIGSTDCALL CSharp_swig_generated_method___(void *jarg1) { int jresult; //SWIG generated *// inject code here like mutex begin* /* SWIG generated code */ jresult = result; *// inject code here like mutex end* return jresult; } Best regards, Prajjwal |