Re: migrating libswigpy to the new swig runtime paradigm in ghmm (and its wrapper)

Edward Ocampo-gooding wrote:
> On 7/31/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:
>> Edward Ocampo-gooding wrote:
>>> Hi,
>>>
>>> Are there any plans to migrate the latest ghmm-wrapper setup.py to
>>> work with the way SWIG is now set up (without a compiled
>>> shared-runtime libswigpy library)?
>>>
>> This mailing list is for swig users, not ghmm users, so you are best off
>> asking on a ghmm mailing list. We can answer questions on any problems
>> you have in when you come to generate your own libswigpy.so library.
>>
>> William
>>
> 
> Sorry about that; I meant this to be for the ghmm guys.
> 
> However, I would like to know more about generating the libswigpy.so
> 
> I'm a bit confused as to how I do it. I know that there's now a
> command-line option to have swig generate a header that contains all
> the function names for the python runtime, but what would I compile it
> with to generate the shared object (libswigpy.so)?
> 
> I'm also aware of the fact that swig is smart enough to compile in the
> runtime if it's needed, but what I believe is happening with the ghmm
> tool is that it links several objects together which have each had
> swig run on them, which would usually create duplicated symbols
> (except if you compiled without the runtime and linked it in later,

Re: Director is not deleted properly

Thomas Dudziak wrote:
> On 7/31/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:
> 
>> Did you try this with 1.3.29? This version has some fixes to release
>> some unnecessary local references.
> 
> Yep, this was tested with 1.3.29 (it's using the new wstring typemaps).
> 

I havn't much time to look at this, but it would be worth looking at
SWIG_DIRECTOR_OWNED in java.swg and the swigTakeOwnership() and
swigReleaseOwnership() methods in the director proxy class and let us
know how you get on as I don't think any of this was documented.

William

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

compilation issue with msvc71 + stlport

xxxxxxxxx_wrap.cxx(2604) : error C2440: 'type cast' : cannot convert 
from 'const char [24]' to '_STL::invalid_argument'
         No constructor could take the source type, or constructor 
overload resolution was ambiguous
         xxxxxxxxxx_wrap.cxx(2604) : see reference to class template 
instantiation '_STL::basic_string<_CharT,_Traits,_Alloc>' being compiled
         with
         [
             _CharT=char,
             _Traits=_STL::char_traits<char>,
             _Alloc=_STL::allocator<char>
         ]
and so on...

the same issue was found in boost library mailing list, and was fixed by 
including <string> before <stdexcept>.
I attempt to fix it in swig std_except.i files, but had no success, 
sorry. :)

So, it'd be great if you fix it in swig-way. thank you.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

std_map.i and RTLD_GLOBAL for python modules

I'm having problems finding the correct options that are needed to
compile and link a python module on linux that throws an exception in
one dynamically loaded module which is caught in another dynamically
loaded module.  I've seen this issue on two different linux
distributions: gentoo, gcc 3.4.6, python 2.4.3 or ubuntu dapper,
python 2.4.3, gcc 4.0.3 which both are using the CVS version of SWIG.
This problem can be fixed with setting the RTLD_GLOBAL flag on dlopen
but I'd like to avoid this solution.

This type of problem occurs when one is using std_map.i  Consider the
following interface:

%module foo

%{
#include "foo.h"
%}

%include std_string.i
%include std_pair.i
%include std_map.i

%naturalvar FooMap;
%template() std::pair< std::string, Foo >;
%template(FooMap) std::map< std::string, Foo >;

%include "foo.h"

with Foo defined as:

Java director and AttachCurrentThread

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Swig-user mailing list
Swig-user <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-user

conditionally load native libraries?

Hi,

I have two libraries that are built with the same source code (read:
have the save API), but certain defines are set when each library is
built so that the behavior of the libraries differ (e.g. use hardware
accelerated crypto or not). A single .i works just fine with Java
because the application must load the library (i.e. call
System.loadLibrary). But with Python this doesn't work since the
Python source code produced by SWIG makes the "import _foobar" call
that will always load only one of the two libraries.

Is there a way to either have the application make the appropriate
"import _foobar" call, or set this up so that the import statement is
conditional inside the SWIG produced Python source code?

Thanks.

-Tom

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Director is not deleted properly

On 8/1/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:

> I havn't much time to look at this, but it would be worth looking at
> SWIG_DIRECTOR_OWNED in java.swg and the swigTakeOwnership() and
> swigReleaseOwnership() methods in the director proxy class and let us
> know how you get on as I don't think any of this was documented.

>From what I can see, it has nothing to do with ownership (the C++
listener object is owned by Java as it should be), but rather with the
fact, that callin methods of the C++ listener in a different C++
thread results in two different jenv's being used. So it might be that
one of the two jenvs is not properly released or something ?
You can have a look yourself on what is going on via the log below.
Basically, I added log statements at the beginning and end of every
method in the swig generated C++/C code. The log below is the output
generated by running the Java test program that I attached to the last
mail.

Tom

-----------------

[Java_swigtest_swigtestJNI_swig_1module_1init] Entering:
jenv=003E627C, jcls=0013F464
[Java_swigtest_swigtestJNI_swig_1module_1init] Exiting
[Java_swigtest_swigtestJNI_new_1Listener] Entering: jenv=003E627C, jcls=0013F800
[JObjectWrapper::JObjectWrapper] Creating new wrapper object: 0092888C
[Director::Director] Entering: this=00928884, jenv=003E627C
[Director::Director] Exiting: this=00928884
[SwigDirector_Listener::SwigDirector_Listener] Creating director
object: 00928880
[Java_swigtest_swigtestJNI_new_1Listener] Exiting: jresult=9603200
[Java_swigtest_swigtestJNI_Listener_1director_1connect] Entering:
jenv=003E627C, jcls=0013F7F0, jself=0013F808, objarg=9603200,
jswig_mem_own=
, jweak_global=

[SwigDirector_Listener::swig_connect_director] Entering:
this=00928880, jenv=003E627C, jself=0013F808, jcls=00B28D78,
swig_mem_own=1, weak_global=1
[Director::swig_set_self] Entering: this=00928884, jenv=003E627C,
jself=0013F808, mem_own=1, weak_global=1
[JObjectWrapper::set] Entering: this=0092888C, jenv=003E627C,
jobj=0013F808, mem_own=1, weak_global=1
JObjectWrapper::set(0013F808, weak_global) -> 00B0EC68
[JObjectWrapper::JObjectWrapper] Exiting this=0092888C, return=true
[Director::swig_set_self] Exiting: this=00928884, return=1
[SwigDirector_Listener::swig_connect_director] Exiting: this=00928880
[Java_swigtest_swigtestJNI_Listener_1director_1connect] Exiting
[Java_swigtest_swigtestJNI_new_1Test] Entering: jenv=003E627C, jcls=0013F828
[Java_swigtest_swigtestJNI_new_1Test] Exiting: jresult=9603288
[Java_swigtest_swigtestJNI_Test_1addListener] Entering: jenv=003E627C,
jcls=0013F828, jarg1=9603288, jarg2=9603200
[Java_swigtest_swigtestJNI_Test_1addListener] Exiting
[Java_swigtest_swigtestJNI_Test_1start] Entering: jenv=003E627C,
jcls=0013F838, jarg1=9603288
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36458
[Director::swig_get_self] Exiting: this=00928884, return=00B36458
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36460
[Director::swig_get_self] Exiting: this=00928884, return=00B36460
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36468
[Director::swig_get_self] Exiting: this=00928884, return=00B36468
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36470
[Director::swig_get_self] Exiting: this=00928884, return=00B36470
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36478
[Director::swig_get_self] Exiting: this=00928884, return=00B36478
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36480
[Director::swig_get_self] Exiting: this=00928884, return=00B36480
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36488
[Director::swig_get_self] Exiting: this=00928884, return=00B36488
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36490
[Director::swig_get_self] Exiting: this=00928884, return=00B36490
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B36498
[Director::swig_get_self] Exiting: this=00928884, return=00B36498
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=00B36174
[Director::swig_get_self] Entering: this=00928884, jenv=00B36174
[JObjectWrapper::get] Entering: this=0092888C, jenv=00B36174
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B364A0
[Director::swig_get_self] Exiting: this=00928884, return=00B364A0
[SwigDirector_Listener::callback] Exiting: this=00928880
[SwigDirector_Listener::callback] Entering: this=00928880
[Director::swig_acquire_jenv] Entering: this=00928884
[Director::swig_acquire_jenv] Exiting: this=00928884, env=003E627C
[Director::swig_get_self] Entering: this=00928884, jenv=003E627C
[JObjectWrapper::get] Entering: this=0092888C, jenv=003E627C
JObjectWrapper::get(00B0EC68) -> return new local ref
[JObjectWrapper::get] Exiting: this=0092888C, return=00B28D78
[Director::swig_get_self] Exiting: this=00928884, return=00B28D78
[SwigDirector_Listener::callback] Exiting: this=00928880
[Java_swigtest_swigtestJNI_Test_1start] Exiting
[Java_swigtest_swigtestJNI_Test_1removeListener] Entering:
jenv=003E627C, jcls=0013F828, jarg1=9603288, jarg2=9603200
[Java_swigtest_swigtestJNI_Test_1removeListener] Exiting

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Director is not deleted properly

On 8/2/06, Thomas Dudziak <tomdzk <at> gmail.com> wrote:
> On 8/1/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:
>
> > I havn't much time to look at this, but it would be worth looking at
> > SWIG_DIRECTOR_OWNED in java.swg and the swigTakeOwnership() and
> > swigReleaseOwnership() methods in the director proxy class and let us
> > know how you get on as I don't think any of this was documented.
>
> From what I can see, it has nothing to do with ownership (the C++
> listener object is owned by Java as it should be), but rather with the
> fact, that callin methods of the C++ listener in a different C++
> thread results in two different jenv's being used. So it might be that
> one of the two jenvs is not properly released or something ?

After reading a bit in
http://java.sun.com/docs/books/jni/html/other.html and related
chapters, I came to the realization, that the code seems to be
perfectly fine.
However, there's still the issue that the VM does not shut down when
the callback is actually called. After spending quite some time on
this, I'm out of ideas here, so please, if anybody has an idea ?

Tom

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Fwd: array of arrays back to perl

---------- Forwarded message ----------
From: Jason Stewart <jason.e.stewart <at> gmail.com>
Date: Aug 3, 2006 11:01 AM
Subject: Re: [Swig-user] array of arrays back to perl
To: "Conklin, Robert (FID)" <Robert.Conklin <at> morganstanley.com>

Hi Robert,

Yes, this can be done. I don't know if there is an existing output
typemap in the SWIG lib that you can use or if you have to write on
yourself.

Cheers, jas.

On 7/28/06, Conklin, Robert (FID) <Robert.Conklin <at> morganstanley.com> wrote:
>
>
>
>
> Hi,
> I am trying to get the correct typemap(argout) to have an array of array
> returned to perl from C. I have tried numerous typemaps and I just can't get
> it correct. First off can this be done ? If so  can someone point me in the
> right direction.
>
> Thanks
> Bob
>  ________________________________
>
> This is not an offer (or solicitation of an offer) to buy/sell the
> securities/instruments mentioned or an official confirmation.  Morgan
> Stanley may deal as principal in or own or act as market maker for
> securities/instruments mentioned or may advise the issuers.  This is not
> research and is not from MS Research but it may refer to a research
> analyst/research report.  Unless indicated, these views are the author's and
> may differ from those of Morgan Stanley research or others in the Firm.  We
> do not represent this is accurate or complete and we may not update this.
> Past performance is not indicative of future returns.  For additional
> information, research reports and important disclosures, contact me or see
> https://secure.ms.com/servlet/cls.  You should not use
> e-mail to request, authorize or effect the purchase or sale of any security
> or instrument, to send transfer instructions, or to effect any other
> transactions.  We cannot guarantee that any such requests received via
> e-mail will be processed in a timely manner.  This communication is solely
> for the addressee(s) and may contain confidential information.  We do not
> waive confidentiality by mistransmission.  Contact me if you do not wish to
> receive these communications.  In the UK, this communication is directed in
> the UK to those persons who are market counterparties or intermediate
> customers (as defined in the UK Financial Services Authority's rules).
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> Swig-user mailing list
> Swig-user <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/swig-user
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Director is not deleted properly

Thomas Dudziak <tomdzk <at> gmail.com> writes:

> 
> On 8/2/06, Thomas Dudziak <tomdzk <at> gmail.com> wrote:
> > On 8/1/06, William S Fulton <wsf <at> fultondesigns.co.uk> wrote:
> >
> > > I havn't much time to look at this, but it would be worth looking at
> > > SWIG_DIRECTOR_OWNED in java.swg and the swigTakeOwnership() and
> > > swigReleaseOwnership() methods in the director proxy class and let us
> > > know how you get on as I don't think any of this was documented.
> >
> > From what I can see, it has nothing to do with ownership (the C++
> > listener object is owned by Java as it should be), but rather with the
> > fact, that callin methods of the C++ listener in a different C++
> > thread results in two different jenv's being used. So it might be that
> > one of the two jenvs is not properly released or something ?
> 
> After reading a bit in
> http://java.sun.com/docs/books/jni/html/other.html and related
> chapters, I came to the realization, that the code seems to be
> perfectly fine.
> However, there's still the issue that the VM does not shut down when
> the callback is actually called. After spending quite some time on
> this, I'm out of ideas here, so please, if anybody has an idea ?
> 

The JNIEnv pointer is only valid in the current thread. I can't see any
violation of this rule. However, you are creating native threads that the jvm
does not know about. In order to get a valid JNIEnv pointer, the
AttachCurrentThread is called in swig_acquire_jenv(). From what I understand,
there should be a DetachCurrentThread after the JNIEnv pointer is finished with,
but I don't see any such calls. I suspect that one should be generated at the
end of each of the Director class methods, eg SwigDirector_Listener::callback in
your case.

There was another email posted yesterday about AttachCurrentThread and Java
directors which talks about this too.

William

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV