headers
Bill Davy | 1 Jun 2005 11:41

Re: DLL load failed: The specified procedure could not be found

"John Machin" <sjmachin <at> lexicon.net> wrote in message 
news:429cf3cf$1 <at> news.eftel.com...

>> a) What "specified procedure "
>> b) SHIP was made by SWIG
>
> and so presumably was _SHIP ... therefore it appears that you might be

> better off asking for help on the SWIG mailing list.

I will too.

>
>> c) Is there some way to find out which DLL and which procedure is 
>> involved?
>
> One would expect given the reported context (import _SHIP) that it has

> found (somewhere!) a DLL called "_SHIP.pyd" and is looking in it 
> (unsuccessfully) for an entrypoint called "init_SHIP".
>
> The usual suspect here would be the C (or C++) compiler messing with
the 
> name of the entrypoint; possible messes include underscores at the
front 
> and/or frame size at the end e.g. "_initfoo <at> 12" instead of just
"initfoo". 
> Possibly you are using a C[++] compiler that's not the one that SWIG 
> thinks you are using.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jose Silva | 1 Jun 2005 16:58
Picon

typemaps.i

Hi I'm using some typemaps defined in "typemaps.i", but something is
not as I thought it would be. when using the %apply I thought that
SWIG would use typedef reductions and would wrap correctly, but this
is not happening. Can anybody point me out what I'm doing wrong?

 This is what I have.

example.i

...
%include "typemaps.i"
%apply unsigned short &INPUT {D &value};

%template(AAA_UInt32AvpWidget)
AAA_AvpWidget<diameter_unsigned32_t,AAA_AVP_UINTEGER32_TYPE>;
....

the class in cause:

typedef unsigned short diameter_unsigned32_t;
typedef AAA_AvpWidget<diameter_unsigned32_t,             
AAA_AVP_UINTEGER32_TYPE> AAA_UInt32AvpWidget;

template<class D, AAA_AVPDataType t>
class AAA_AvpWidget {
    public:
        AAA_AvpWidget(char *name) {
            AAAAvpContainerManager cm;
            m_cAvp = cm.acquire(name);
        }
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcelo Matus | 1 Jun 2005 18:38
Picon

Re: typemaps.i

Jose Silva wrote:

>Hi I'm using some typemaps defined in "typemaps.i", but something is
>not as I thought it would be. when using the %apply I thought that
>SWIG would use typedef reductions and would wrap correctly, but this
>is not happening. Can anybody point me out what I'm doing wrong?
>
> This is what I have.
>
>example.i
>
>...
>%include "typemaps.i"
>%apply unsigned short &INPUT {D &value};
>  
>

What is 'D'?, maybe what you need to do

  %include "typemaps.i"
  %apply unsigned short &INPUT {diameter_unsigned32_t &value};

or just be sure you are exposing the typedef

 
  typedef unsigned short diameter_unsigned32_t;

in the swig interface at the right time, ie, before the %template directive.

Marcelo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jacque Mergens | 2 Jun 2005 14:37
Picon

FAQ location

Can someone point me to the FAQ for this list?

Jacque
_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Permalink | Reply | 1 comment |
headers
Jacque Mergens | 2 Jun 2005 15:28
Picon

Compiling examples

I am a newbie to SWIG.  I can't seem to get the example to compile.  I
am using the standard one called out in the manual but it keeps
complaining throwing error on data types.

I am running SuSE 9.2
SWIG 1.3.21

Has anyone had this problem before?

Jacque
_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Permalink | Reply | 3 comments |
headers
Keith Sabine | 2 Jun 2005 15:32
Picon

swig question

Hi,

I would appreciate some help from the SWIG experts....

I have a C++ application with the API wrapped using SWIG for python.
I want to be able be able to import python modules and call python
functions from C++, passing them parameters which are SWIG wrapped C 
pointers.

e.g. if I have (rather simplified):

class fred
{
    void doSomething();
}

and python code:

def foo(f) :
    f.doSomething()

then from C++ within a function of 'fred' to call  it e.g:

PyObject *pArgs = PySwigObject_FromVoidPtrAndDesc((void *) this, "fred");
PyObject * pFunc = PyDict_GetItemString(pDict, "foo");
pValue = PyObject_CallObject(pFunc, pArgs);

Here I'm assuming that I need to call the function with an argument that 
is a
SWIG pointer object. Only it doesn't work - the PyObject_CallObject
(Continue reading)

Permalink | Reply | 5 comments |
headers
Keith Sabine | 2 Jun 2005 18:41
Picon

Re: swig question

Bit more info - if I add a print statement to the python code like:

def foo(f) :
   print "arg 1 is ", f
   f.doSomething()

then I get a message from Python like:

arg 1 is  _2004a37f_p_fred

which seems to indicate that Python understands the C++ 'this' pointer is
for a 'fred' object, and the address is correct, yet the traceback tells me:

AttributeError: 'PySwigObject' object has no attribute 'doSomething'

which seems to imply that the PySwigObject is not a 'fred' object
that has been wrapped by SWIG... odd.

I'm sure other people must have tried passing wrapped C++ objects
to Python, yet there doesn't seem to be any info on how to do it.

thanks,

Keith
_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
Permalink | Reply | 4 comments |
headers
Josh Cherry | 2 Jun 2005 19:26
Picon
Favicon

Re: swig question


On Thu, 2 Jun 2005, Keith Sabine wrote:

> arg 1 is  _2004a37f_p_fred
>
> which seems to indicate that Python understands the C++ 'this' pointer is
> for a 'fred' object, and the address is correct, yet the traceback tells me:
>
> AttributeError: 'PySwigObject' object has no attribute 'doSomething'
>
> which seems to imply that the PySwigObject is not a 'fred' object
> that has been wrapped by SWIG... odd.

You've created the appropriate PySwigObject representation of 'this', but
you haven't created a Python fred object that contains it.  You should be
able to pass your PySwigObject to the fredPtr constructor and get back
what you want.  Better might be to find the type info based on the class
name and call SWIG_Python_NewPointerObj; perhaps there's already a
function that does this.

When I've played with this sort of thing, I've created and wrapped a
function that takes an integral type, casts it to a pointer to the class I
want to create, and returns it.  Then I just call the Python wrapper for
this function from C++, casting the pointer to the integral type.

You might also want to look into directors.

Josh

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcelo Matus | 2 Jun 2005 22:21
Picon

Re: swig question

How are you creating 'f' ?

Marcelo

Keith Sabine wrote:

> Bit more info - if I add a print statement to the python code like:
>
> def foo(f) :
>   print "arg 1 is ", f
>   f.doSomething()
>
> then I get a message from Python like:
>
> arg 1 is  _2004a37f_p_fred
>
> which seems to indicate that Python understands the C++ 'this' pointer is
> for a 'fred' object, and the address is correct, yet the traceback 
> tells me:
>
> AttributeError: 'PySwigObject' object has no attribute 'doSomething'
>
> which seems to imply that the PySwigObject is not a 'fred' object
> that has been wrapped by SWIG... odd.
>
> I'm sure other people must have tried passing wrapped C++ objects
> to Python, yet there doesn't seem to be any info on how to do it.
>
> thanks,
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Josh Cherry | 2 Jun 2005 22:29
Picon
Favicon

trouble with typedefs

SWIG is hanging when it encounters certain legal typedef combinations,
apparently because it is not properly dealing with class scope.  Consider
the following simple example:

class Foo
{
};

typedef Foo Bar;

class CBaz
{
public:
    typedef Bar Foo;
};

This is legal C++: Foo and CBaz::Foo are distinct, so there's no
circularity.  However, SWIG hangs on this, presumably going into an
infinite loop resolving Foo to Bar and Bar back to Foo.

Josh

--
Joshua L. Cherry, Ph.D.
NCBI/NLM/NIH (Contractor)
jcherry <at> ncbi.nlm.nih.gov

_______________________________________________
Swig maillist  -  Swig <at> cs.uchicago.edu
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
(Continue reading)

Permalink | Reply | 1 comment |

Gmane