Re: Swig-lua internals

>Hello swig list,
>   I'm attempting to write an auto-complete system in a
> C++ based Lua code
> editor, which involves retrieving the list of member
> functions that wrapped
> object might have. I'm wondering if anyone might have a
> suggestion or two.
> 
> Thanks for any suggestions.
> -Gedalia
> 
Hello Gedalia,
Its not really a problem to do this, but you will need to proficient/brave enough to read the C++ source code 
I wrote this code up in about 10 minutes, it prints the names of all the classes in the code, and methods.
It only lists the classes methods, not base classes, but it will put you an the right track.

%inline %{
void printWrappedClasses()
{
    //this touches the SWIG internals, please be careful:
  for (int i = 0; swig_types[i]; i++){
    if (swig_types[i]->clientdata){
      swig_lua_class* ptr=(swig_lua_class*)(swig_types[i]->clientdata);
      printf("%s\n",ptr->name);
    }
  }
}

void printMethods(const char* name)
{

Re: Swig-lua internals

Thanks Mark,
  I did read the c++ code but since almost all the functionality that I needed was declared static to the autogenerated file, I wasn't sure how to get at it from the outside. It hadn't occurred to me that I should add the code to the swig file.
Thanks for the suggestion.
-Gedalia

On Mon, Jun 30, 2008 at 9:54 PM, Mark Gossage <mark <at> gossage.cjb.net> wrote:

>Hello swig list,
>   I'm attempting to write an auto-complete system in a
> C++ based Lua code
> editor, which involves retrieving the list of member
> functions that wrapped
> object might have. I'm wondering if anyone might have a
> suggestion or two.
>
> Thanks for any suggestions.
> -Gedalia
>
Hello Gedalia,
Its not really a problem to do this, but you will need to proficient/brave enough to read the C++ source code
I wrote this code up in about 10 minutes, it prints the names of all the classes in the code, and methods.
It only lists the classes methods, not base classes, but it will put you an the right track.

%inline %{
void printWrappedClasses()
{
   //this touches the SWIG internals, please be careful:
 for (int i = 0; swig_types[i]; i++){
   if (swig_types[i]->clientdata){
     swig_lua_class* ptr=(swig_lua_class*)(swig_types[i]->clientdata);
     printf("%s\n",ptr->name);
   }
 }
}

void printMethods(const char* name)
{
   //this touches the SWIG internals, please be careful:
 for (int i = 0; swig_types[i]; i++){
   if (swig_types[i]->clientdata){
     swig_lua_class* ptr=(swig_lua_class*)(swig_types[i]->clientdata);
     if (strcmp(name,ptr->name)==0){
       // get the methods
       // ps you could also look at attributes in the same way
       for(int j=0;ptr->methods[j].name;j++){
         printf("%s::%s()\n",ptr->name,ptr->methods[j].name);
       }
     }
   }
 }
}

%}

I wrapped these and called from Lua, but you could easily call it from C++.

Let me know if you have any other questions.
Regards,
Mark


     __________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

--
---------------------------------------------------------------
cel: 917.776.8346 AIM: gedaliap
http://www.gedalia.net
---------------------------------------------------------------
Fight Entropy!!! Fight Entropy!!! Figth Etnropy! !
iFgth Etnrop!y ! giFth tErno!py ! giFt htrEno!p y! --- Well maybe
not...

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

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

Re: sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)

[retrying]

So far I could only see one solution:

http://patches.ubuntu.com/by-release/extracted/ubuntu/o/openbabel/2.1.1-4/some_platform_have_no_python_dl.patch

So they ship a pregenerated swig .py file in the distribution that
they manually modified. Is this the ony way of patch the swig
generated file ? Isn't there an automated ?

Thanks
-Mathieu

On Sat, Jun 28, 2008 at 1:35 AM, Mathieu Malaterre
<mathieu.malaterre <at> gmail.com> wrote:
> Hi there,
>
> I can find a couple of references for the issue with RTLD_GLOBAL in
> the swig mailing list:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=4589C31B.10100%40fultondesigns.co.uk
> http://thread.gmane.org/gmane.comp.programming.swig.devel/14431/focus=14462
> http://osdir.com/ml/programming.swig/2003-07/msg00000.html
>
>  Has there been any mechanism to generate those extra lines (something like):
>
> if dl and (os.name == 'posix'):
>    sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
>
>  Or what is the recommended way so that those line appears at the top
> of my siwg generated module ?
>
> Thanks,
> --
> Mathieu
>

--

-- 
Mathieu

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)

Done:

http://gdcm.svn.sourceforge.net/viewvc/gdcm/trunk/Wrapping/Python/gdcm.py?view=markup

I have a hand written gdcm module, that simply load the python
swig-generated module...

-Mathieu

On Tue, Jul 1, 2008 at 11:25 AM, Mathieu Malaterre
<mathieu.malaterre <at> gmail.com> wrote:
> [retrying]
>
> So far I could only see one solution:
>
> http://patches.ubuntu.com/by-release/extracted/ubuntu/o/openbabel/2.1.1-4/some_platform_have_no_python_dl.patch
>
> So they ship a pregenerated swig .py file in the distribution that
> they manually modified. Is this the ony way of patch the swig
> generated file ? Isn't there an automated ?
>
> Thanks
> -Mathieu
>
> On Sat, Jun 28, 2008 at 1:35 AM, Mathieu Malaterre
> <mathieu.malaterre <at> gmail.com> wrote:
>> Hi there,
>>
>> I can find a couple of references for the issue with RTLD_GLOBAL in
>> the swig mailing list:
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=4589C31B.10100%40fultondesigns.co.uk
>> http://thread.gmane.org/gmane.comp.programming.swig.devel/14431/focus=14462
>> http://osdir.com/ml/programming.swig/2003-07/msg00000.html
>>
>>  Has there been any mechanism to generate those extra lines (something like):
>>
>> if dl and (os.name == 'posix'):
>>    sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
>>
>>  Or what is the recommended way so that those line appears at the top
>> of my siwg generated module ?
>>
>> Thanks,
>> --
>> Mathieu
>>
>
>
>
> --
> Mathieu
>

--

-- 
Mathieu

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Re: sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)

Mathieu Malaterre wrote:
> Hi there,
> 
> I can find a couple of references for the issue with RTLD_GLOBAL in
> the swig mailing list:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=4589C31B.10100%40fultondesigns.co.uk
> http://thread.gmane.org/gmane.comp.programming.swig.devel/14431/focus=14462
> http://osdir.com/ml/programming.swig/2003-07/msg00000.html
> 
>   Has there been any mechanism to generate those extra lines (something like):
> 
> if dl and (os.name == 'posix'):
>     sys.setdlopenflags(dl.RTLD_NOW|dl.RTLD_GLOBAL)
> 
>   Or what is the recommended way so that those line appears at the top
> of my siwg generated module ?

I also had a problem with this and would welcome a SWIG approach to either
specifically handle the dlopen global issue, or to allow prepending of
aribtrary Python code at the start of the generated module.

But for now I do some ugly stuff with this autotools Makefile.am fragment and
script:

In Makefile(.am):
------
all-local:
     <at> sh fixpyrivet
------
NB. this is for a Python module called pyrivet.

and here's fixpyrivet
------
if test -f pyrivet.py; then
  if test -z "$( grep RTLD_GLOBAL pyrivet.py )"; then
    cp pyrivet.py pyrivet.py.bak
    echo "## dlopen global workaround" > pyrivet.py
    echo "import sys, dl" >> pyrivet.py
    echo "flags = sys.getdlopenflags()" >> pyrivet.py
    echo "sys.setdlopenflags(flags | dl.RTLD_GLOBAL)" >> pyrivet.py
    echo "" >> pyrivet.py
    cat pyrivet.py.bak >> pyrivet.py
    rm -f pyrivet.py.bak
  fi
fi
------

Very ugly, but it works on POSIX systems, which is all that I need for now. I
may change it to use a slightly more careful import as in your example. A SWIG
directive to portably solve this problem without having to resort to mangling
the generated module would be infinitely preferable!

Andy

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

unsigned char* manipulations

Hello,
I have a c++ class that has the following data functions:
unsigned char* getSentDataP();
uint32_t getSentDataSize() const;

I've managed wrapping them with python using swig by converting unsigned
char* to char * and vice versa.
unfortunately when checking the received data I get incorrect CRC.

When dug deeper I figured out that I'm not getting the right amount of data.
the c++ function declares on a certain size while len(p.getSentDataP())
returns a different size (the difference is inconsistent for different data
packets).

Would appreciate any advice
Hannit
--

-- 
View this message in context: http://www.nabble.com/unsigned-char*-manipulations-tp18231857p18231857.html
Sent from the swig-user mailing list archive at Nabble.com.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

segfault on inclusion of std_vector.i

I am using swig to generate a ruby interface for some c++ code I've
written.  I want to include std_vector so that (hopefully) I input
ruby arrays into this method I have that accepts std::vector<int>.

anyways, if I build without..
%include std_vector.i
..my application builds fine, I can run my it but I cannot use this
method in ruby.

If I do include that I get this output:

$ swig -Wall -c++ -ruby datajockey.i
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:136: Warning(322):
Redundant redeclaration of 'map_bang',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:136: Warning(322):
previous declaration of 'map_bang'.
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:136: Warning(322):
Redundant redeclaration of '__delete__',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:136: Warning(322):
previous declaration of '__delete__'.
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:137: Warning(322):
Redundant redeclaration of 'map_bang',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:137: Warning(322):
previous declaration of 'map_bang'.
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:137: Warning(322):
Redundant redeclaration of '__delete__',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:137: Warning(322):
previous declaration of '__delete__'.
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:138: Warning(322):
Redundant redeclaration of 'map_bang',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:138: Warning(322):
previous declaration of 'map_bang'.
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:138: Warning(322):
Redundant redeclaration of '__delete__',
/usr/share/swig1.3/ruby/rubycontainer_extended.swg:138: Warning(322):
previous declaration of '__delete__'.

then, after building and running my app I get a segfault right away.

below is the gdb backtrace.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb60f0ac0 (LWP 21283)]
0xb7e1324e in st_lookup () from /usr/lib/libruby1.8.so.1.8
(gdb) bt
#0  0xb7e1324e in st_lookup () from /usr/lib/libruby1.8.so.1.8
#1  0xb7de74e2 in rb_intern () from /usr/lib/libruby1.8.so.1.8
#2  0x080863dc in __static_initialization_and_destruction_0 ()
#3  0x0809e2b5 in __do_global_ctors_aux ()
#4  0x08054820 in _init ()
#5  0x0809e259 in __libc_csu_init ()
#6  0xb6f853f1 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#7  0x08057091 in _start ()

Any ideas what's up?  Am I doing something wrong or, is there a bug in
the swig-ruby library?

btw, while building [with and without that include statement], i get a
bunch of these:
swig/datajockey_wrap.cxx:5463: warning: unused parameter 'self'
swig/datajockey_wrap.cxx:5479: warning: unused parameter 'argv'
....
and a couple of these:
swig/datajockey_wrap.cxx: In function 'VALUE
_wrap_new_MixerPanelModel(int, VALUE*, VALUE)':
swig/datajockey_wrap.cxx:5193: warning: 'argv[0]' may be used
uninitialized in this function

Thanks,
Alex

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: unsigned char* manipulations

some more data:
Seems like the problem is related to the fact that the original data is
binary ans python (of course) converts it to a string.
I assume that if I could read it into a StringIO or cStringIO buffers things
would work fine.
any idea how to do that ?

hannit wrote:
> 
> Hello,
> I have a c++ class that has the following data functions:
> unsigned char* getSentDataP();
> uint32_t getSentDataSize() const;
> 
> I've managed wrapping them with python using swig by converting unsigned
> char* to char * and vice versa.
> unfortunately when checking the received data I get incorrect CRC.
> 
> When dug deeper I figured out that I'm not getting the right amount of
> data.
> the c++ function declares on a certain size while len(p.getSentDataP())
> returns a different size (the difference is inconsistent for different
> data packets).
> 
> Would appreciate any advice
> Hannit
> 

--

-- 
View this message in context: http://www.nabble.com/unsigned-char*-manipulations-tp18231857p18235336.html
Sent from the swig-user mailing list archive at Nabble.com.

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: unsigned char* manipulations

On Wed, 2 Jul 2008, hannit wrote:

>
> some more data:
> Seems like the problem is related to the fact that the original data is
> binary ans python (of course) converts it to a string.
> I assume that if I could read it into a StringIO or cStringIO buffers things
> would work fine.
> any idea how to do that ?
>
>
> hannit wrote:
>>
>> Hello,
>> I have a c++ class that has the following data functions:
>> unsigned char* getSentDataP();
>> uint32_t getSentDataSize() const;
>>
>> I've managed wrapping them with python using swig by converting unsigned
>> char* to char * and vice versa.
>> unfortunately when checking the received data I get incorrect CRC.
>>
>> When dug deeper I figured out that I'm not getting the right amount of
>> data.
>> the c++ function declares on a certain size while len(p.getSentDataP())
>> returns a different size (the difference is inconsistent for different
>> data packets).
>>
>> Would appreciate any advice
>> Hannit

I would use %extend to add a function that returns a std::string.

Josh

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: unsigned char* manipulations

hannit wrote:
> Seems like the problem is related to the fact that the original data is
> binary ans python (of course) converts it to a string.

well, despite its name, a python string is really just an array of 
bytes, so it is an appropriate type for a char pointer.

>> I have a c++ class that has the following data functions:
>> unsigned char* getSentDataP();

This is a pointer, how do you know how long the data block is? SWIG is 
going to need to know that to create a python string.

-Chris

--

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker <at> noaa.gov

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08